Comic by Scott Adams
User stories are critical artifacts in any Agile project. It allows stakeholders communicate their requirements to the development team in an integral fashion.
But why are user stories so powerful?
Because they communicate the purpose of a requirement from the user’s point of view.
Say that you own a very popular news website and want to built an online form to allow visitors report feedback.
Let’s list the requirements of that feature in an ordinary way:
- Implement feedback form to allow visitors report issues or recommendations about the website.
- Collect information submitted through feedback form in database.
- Capture browser settings from visitor when s/he submits the feedback through the form.
- Ability to export feedback database to a spreadsheet.
Those three points look sufficient at a glance, and a developer could probably start working with those directions, but if we examine that in more detail we’ll find some flaws:
- Implement feedback form to allow visitors report issues or recommendations about the website – WHY?
- Collect information submitted through feedback form in database – WHO and WHY?
- Capture browser settings from visitor when s/he submits the feedback through the form – WHY?
- Ability to export feedback database to a spreadsheet – WHO and WHY?
User stories answer all those questions (who, what, why), and make requirements easier to understand even for non-technical people.
User stories usually follow this template:
|As a <type of user>||→ who is this story for|
|I want <some goal>||→ what they want to do it|
|so that <some reason>||→ why they want to do it|
Now, let’s try to define those requirements with user stories:
- As an Admin user, I would like to enable a web form to allow visitors (anonymous users) report website issues so I get notified immediately and get them fixed as soon as possible.
- As an Admin user, I would like to enable a web form to allow visitors (anonymous users) report recommendations about my site so I identify from my target audience what needs to be improved.
- As an Admin user, I would like to capture browser settings and OS from the visitor who reports the problem so I share that information with my development team to replicate the problem.
- As an Admin user, I would like to search and browse reported issues by date and reporter, so I prioritize the fixes and contact the visitors who provided feedback in case I want to follow up with them.
- As an Admin user, I would like to export all the reported feedback to a spreadsheet so I open that up in Excel to run reports.
As you see, those user stories contain information that will allow the development team to understand the purpose behind those requirements and provide more insightful solutions to the product owner in the Sprint Planning meeting. On the other hand, they contain the business values, and will allow the product owner and stakeholders prioritize them in the Sprint Planning and Backlog Grooming meetings.