The purpose of User Stories in Scrum
Most of the backlogs I work with are made up of user stories. Although they are in no way required for Scrum, they are a useful technique to describe functionality in a just-detailed-enough manner.
But many seasoned analysts and architects cringe at the idea of having to write user stories. To them, it feels like a very sub-optimal and forced way to capture the richness of user requirements. And I completely get that it feels fishy to write user stories, only to have the Development Team come in and ask a ton of questions when they start working on it. Wouldn’t it have been more practical to have captured all the details of the functionality beforehand?
And you know what? This is a valid point,
It is a valid point if you treat User Stories as the only way to specify user functionality. And this is where we run into an important misconception about User Stories. A User Story is not meant to be a complete specification. It serves different purposes:
- A starting point for meaningful conversation and collaboration about what the functionality should be like, assuming that the best way to clarify intent is by talking about it as analysts, developers, architects and product owners
- Provide a functional overview of what the application will be able to do for users, so that the team can (roughly) estimate the work and allow the Product Owner to prioritize quickly
- A way to describe functionality in the simplest way possible so that teams don’t get bogged down in writing and updating specifications whenever scope changes — and it always does
User stories are not supposed to replace complete specifications with a magical method that achieves the same result in a fraction of the time. They are meant as a starting point for further refinement and specification by Scrum Teams. User Stories fit with the Just-In-Time specification that happens in experienced Scrum Teams. They have learned that the best moment to further specify functionality is when they are about to get started on it. Preferably not by passing along specifications on paper (or in a tool like JIRA), but by discussing intent, implementation and test scenarios within the team. It’s perfectly fine if a team then decides to write this down (on paper or in a tool) in the form of a use case, a workflow, a SpecFlow scenario or some other specification. But in this case User Stories have served their purpose; to initiate communication and share knowledge, so that the team can continue building valuable functionality.
