Before we look at why use user stories, let’s first start by looking at other common requirement gathering techniques.
1st, there is the IEEE 830 with “The system shall… “, The system shall do this…, the system shall do that, and my favorite, the system shall be bug free 😊.
We typically start out with an excel spreadsheet or a table in word with about 1000 requirements all in the format of “the system shall….” These are then given to a business analysis team that spend months converting them into functional specs. 1000 requirements, become 30 functional specs, each about 50 pages. Then we hand it over to the developers and testers and tell them here’s what you need to build and test. Go through these 1500 pages and let us know if you have any questions! This process is tedious, error prone, time consuming, boring, hard to see the big picture, hard to prioritize, more task focused instead of being goal or business value focused.
Another option is Use Cases. Use cases do a better job at putting things in context, but are still too detailed to adapt to changing customer needs. They are bigger and larger in scope than a user story. There is the main scenario and then the extensions, and the pre/post conditions. They act more as an agreement between customer and developer rather than a forum for an ongoing conversation.
So let’s look at the advantages of user stories:
1. Support the Agile Manifesto
User stories directly support the Agile manifesto. Obviously, user stories support focusing on working software over comprehensive documentation. The conversation supports individuals and interactions and customer collaboration, and the brevity and high level of a user story supports responding to change as we get closer to implementation.
2. Emphasize Verbal Communication
User stories also emphasize verbal rather than written communication. They encourage conversation, face to face discussions as opposed to document handoffs.
3. Defer Details
User stories encourage deferring details until you have a better understanding about what you really need. This avoids unnecessary detailed planning which might change by the time we reach development time.
4.Support Product Backlog Prioritization
User stories provide the right size for planning. Their high level, with a focus on value makes it easy to prioritize and re-order the product backlog.
User stories are written in business terms and not technical jargon which make them comprehensible by both customers and developers.
6. Support iterative development
User stories start out broad, high level and coarse grained. Via several iterations, they get more and more refined and detailed as we get closer to implementation.
To learn more about user stories, check out the entire Art of Storytelling Series:
- What is a User Story?
- Top 5 Advantages of User Stories
- The 6 Attributes of Effective User Stories – INVEST
- Top 3 Reasons to Split a User Story
- What’s the Right Size for a User Story
- Top 5 Techniques for Splitting a User Story
- What’s the Most Important Part of a User Story?
- 9 User Story Smells and Anti-patterns
- The Art of Storytelling – User Story Smells and Anti-patterns Presentation
Reference and recommend resource: User Stories Applied by Mike Cohn