Stop Trying to Get Better at Writing User Stories

I facilitate a lot of Agile Bootcamps here at Sketch, and I’ve found that one of the main reasons people take the class is that they want to get better at writing user stories. It always comes as a bit of a shock when I tell them that I’m not going to help them.

In order to understand why, it’s important to understand what a user story is. It’s a representation of a small batch of value, something that someone is going to benefit from once you’ve made it available to them. The smaller, the better: smaller stories involve lower risk, less complexity, and less uncertainty. These are the things that make software development go sideways, and small batch delivery is how we steer clear.

Mike Cohn suggests that a user story is a “short, simple description” of a small feature that allows us to move from writing requirements to talking about them. Jeff Patton refers to user stories as “conversation starters”.

Both of these descriptions illustrate how lightweight a user story is. They allude to the idea that there’s not a lot of detail written in them, because the detail is in the conversation. The user story is a structure that necessitates conversation and collaboration by virtue of the fact that there’s no detail.

The user story format (including acceptance criteria) does not hold some magical quality that allows us to express requirements in a way that is perfectly understandable to a development team, thereby eliminating confusion, thereby guaranteeing successful delivery of a feature. The user story recognizes that there is no such thing as a perfectly understandable requirements document. Understanding must come from the conversation between the people asking for the feature and the people who know how to build and deliver it.

The more you focus on the writing of the user story, the more you write. The more you focus on the purpose of the user story, the more you talk. So stop trying to get better at writing user stories, and focus on making sure everyone understands why we’re using them in the first place. If you want better user stories, focus on getting better at these things instead:

• Shrinking stories. How small can you possibly express a feature? Get creative. For example, rather than processing all rules for a data set, start with just one rule. Bonus: smaller stories means there’s less to write!
• Slicing stories. A story is intended to represent the delivery of something valuable to a customer. It is not intended to represent a step along the way. For example, “user can choose to see temperature in F or C” is better than “update API to support F and C”.
  Small stories that represent everyone’s contribution toward delivery are a tool for enabling collaborative conversations. Those conversations allow us to stop writing and start delivering.