At a recent workshop on agile requirements, I was surprised by the number of attendees who had been told that EVERYTHING in their product backlog had to be written in the form of a user story, and specifically in the format described in Mike Cohn’s great book User Stories Applied for Agile Software Development: As a <type of user>, I want <some feature>, so that <some goal>.
Now, I’m a huge proponent of writing user stories. So-called “Requirements” are the hardest part of software, and a user story, when done right, is a great way to make requirements a little bit better. Like many tools, they are most useful when used as intended, namely a quick way to describe a requirement with a bit of context, so that the team knows who to talk to for more details and what problem the feature is trying to solve. They are not the only tool we can use to make our requirements a little better, we have other things like Acceptance Criteria (actually an important part of a user story, the “confirmation” of the three Cs: Card, Conversation, and Confirmation). We have Story Maps, Use Cases, User Persona, and a host of other great tools to use. User Stories are probably the easiest to understand and teach, and maybe for that reason, they are the most common agile requirements tool. I love to use them, as well as the other tools.
But I am also lazy. I abhor anything that smells faintly of “busy work”. Writing a user story for every item in a product backlog smells pretty strongly of policy over pragmatism, or to put it another way, Processes and Tools over Individuals and Interactions. So jump the break and let’s look at when to use the User Story hammer and when to leave it in the toolbelt.