An Introduction to Agile User Stories and Story Walls
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. They are simple customer-centric one- or two-line descriptions of work the team should produce. They are very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. In fact, they are very slim and high-level requirements artifacts. Although they are short, they still have two important characteristics:
1. They represent customer value and are written in the customers’ terminology (The best stories are actually written by customers). They describe an end-result that the customer values, not implementation details.
2. They have clear completion criteria. Customers can describe an objective test that would allow programmers to tell when they’ve successfully implemented the story.
“User stories are promissory notes for future conversation.” — Alistair Cockburn.
Example User Stories
Model: An Online Shopping Mall;
“As an online shopper, I want to view the contents of my shopping cart so that I can verify its contents before purchasing them.”
“The user story is structured to show who wants it (the shopper), what they want (to see their shopping cart) and why (to verify its contents). It is also written in plain English, avoiding technical terms.”
“Using this technique, we can rapidly develop a set of stories that describe how the system should behave, from the user’s viewpoint. There may be several different types of user; for instance, browser, shopper, marketer, content editor, systems administrator, etc., and we can write stories for all of them. This is usually done collaboratively, with a bunch of people writing out cards, grouping them together and reviewing. After a short period we should have a broad idea of what our system should do, encapsulated in a set of user stories, which we call the Product Backlog.” — An Introduction To Agile User Stories.
Important Considerations for Writing User Stories
- Stakeholders write user stories.
- Use the simplest tool e.g. Index cards.
- Terminology used must be users’ friendly.
- It is the start of a conversation and progresses incrementally.
- Develop a glossary of terms.
- It must be clear, unambiguous and manageable.
Importance of User Stories
The user stories first were described as a part of Extreme Programming (XP). It’s author, Bill Wake suggested to use the I.N.V.E.S.T. acronym to underline the key aspects of user stories and at the same time its main advantages:
Epics and Themes
Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Epics are typically lower priority user stories because once the epic works its way towards the top of the work item stack, it is reorganized into smaller ones.
A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.
A story wall is a very common and effective information radiator that displays the status of each card in the current iteration or sprint. Typically, a story wall contains columns that represent a team’s workflow, index cards representing the actual work, user stories and other metadata to communicate the status of a project. The team moves a card through each column as it gets completed.
“We plan our work in small, customer-centric pieces.” — Art of Agile Development.