Minimum Viable User Stories

Agile. How did a movement whose manifesto began with “Individuals and interactions over processes and tools” get so caught up in ceremony?

(“Humans” is the answer)

Thoughtbot tweeted a thought-provoking article on “Replacing the User Story with the Job Story“. I am a fan of “jobs to be done” but do not think this is really much of an improvement.

I personally think that user stories should not be formulaic, and they don’t need to feel like “documentation”. (note: I don’t expect everyone I work with to agree with me)

Shared understanding is what you need, not documentation. Just as I believe in doing the lowest-fidelity design (sketch/wireframe/mockup) necessary to move into successful working code, I feel the same about user stories.

Your entire team should know who your customer is, what you are trying to solve, and why. It shouldn’t be a mystery, and it shouldn’t need to be written up in an artificial sentence.

Put as much, and as little, as you need into your user story to enable clarity and a shared understanding. Remote teams will need more than co-located teams.

The entire team needs to know that if they get confused, they should stop and ask a quick question. Don’t plow ahead with mistaken assumptions, just ask. A resolution doesn’t need a meeting, just a quick touch point.

You don’t need formulaic documentation if you have a trusting, cross-functional team which maintains the discipline of lightweight communication.

  • Corey Innis

    Agreed. I’ve always framed this as: (user) stories are, first and foremost, placeholders for conversation.

  • Josh Seiden

    It’s much easier to change the way you write requirements than to change the way you structure your software development organization. So the move from requirements documents to user stories is trivially easy compared to the hard work of creating small, cross-functional teams that are close to the market.

    Many “agile adoptions” miss this, and end up polishing (and “ceremonializing”) the story-writing process instead of dealing with the core issues.

  • Luke Chamberlin

    Many people underestimate the difficulty of writing a crisp, concise sentence that conveys a singular, unambiguous meaning.

    I think the formulaic “fill-in-the-blanks” user stories are in part a reaction to frustration over poor, unclear writing. You can give that template to an unexperienced (or just plain bad) writer and still get something out of the process.

    • I see that. I’ve found that even a well-structured and written sentence is still a launching pad for mistakes if people aren’t communicating effectively. Per Josh’s comment, it dodges the root issue.

  • IceMonkey

    Another reason that writing well is important across all disciplines. Richard Lanham’s “Revising Prose” (4th Ed.) teaches the “paramedic” method of self-editing, and is a great read for UX’ers responsible for story writing.

  • Debs

    It’s always about the humans and the relationships. Those who try to over document are indeed doing out of [in case they mess it up]

    http://gapingvoid.com/2007/05/19/technology-changes/