Upon completion of this lesson, you will be able to:
User stories are short and intentionally simple descriptions of a feature or affordance needed by a user or consumer of a system. Users are described through roles and are analyzed through personas to differentiate between the different needs of users of the same class. Personas and user stories get at the needs of different types of users in a simple way.
User stories have been primarily used in the context of agile projects, but they represent a more general technique. User stories help elicit, understand, and prioritize stakeholder requirements.
Stories and personas provide analysts and interaction designers with an important and useful tool to obtain and describe requirements from users. They work particularly well for interactive systems.
The Business Analysis Body of Knowledge defines a user story as follows:
“User Stories are a brief description of functionality that users need from a solution to meet a business objective. A user story is a textual description of things that the solution needs to allow users to do. User stories are typically a sentence or two that describes who uses the story, the goal they are trying to accomplish, and any additional information that may be critical to understanding the scope of the story.”
User stories are often expressed in one of these simple formats:
Note that user stories are not sufficient for requirements documentation. They provide brief descriptions that must be further analyzed (and documented if not used in an agile method).
Using the format originally suggested by Mike Cohn, here are two examples of user stories for an online recruiting site:
Here’s an alternative using one of the other formats:
A user story is built around three main elements:
A user story should also define Acceptance and Evaluation Criteria so that it can be tested.
The “so that” clause allows an analyst to get to the “root” of the need and to assure that there’s a valid business need for the requirement. A user story must provide business value to be valid.
In some situations, this may be extended by generating multiple “so that” clauses:
“As a recruiter, I want to post an open position, so that I can find qualified applicants so that I can earn a commission and vso that** I can become part of the ‘10% club’.”
This “root cause” analysis is similar to the “5-Why” technique and can lead to alternate and perhaps more appropriate solutions.
The user story format can be extended to include a “risk” clause that specifies what would happen if the story were not implemented:
“As a recruiter, I want to post an open position, so that I can find qualified applicants. If I don’t, then I won’t earn a commission and the position will remain unfilled or filled with an unqualified applicant.”
User stories are purposely written at a high-level in order not to prescribe a solution.
For example, the story
“As a job seeker, I want to search for a new position, so that I can advance in my career.”
could be implemented in numerous ways:
Specify what the minimum viable solution is and then implement that solution first before “gold plating.”
User stories are not complete without specifying acceptance criteria. Acceptance criteria specify the “boundary” of the story and when work can be considered complete.
For example, the acceptance criteria for the previous story could be:
| Benefits | Challenges |
|---|---|
| Instills customer ownership | Not detailed enough when regulatory restrictions require detailed documentation |
| Useful or iterative and incremental delivery of solutions | May not align with waterfall methods that are documentation centric |
| May eliminate the need for more detailed requirements specifications in agile environments where stakeholders and delivery teams are co-located | Does not document non-functional requirements well and therefore require additional techniques to be used in conjunction with user stories |
| Clearly defines the value that a features provides | Story format may not include enough detail for teams that are distributed |
| Prioritize with story points for time-boxed iterations |
User stories present the needs of a user in a narrative format. They are particularly useful for:
Elicit user stories collaboratively with stakeholders. Start by brainstorming user roles, then personas, and eventually identify user stories. Don’t worry about epics or themes initially; focus on getting what users need.
Write stories on cards; better yet: let the stakeholders themselves write the stories on card to instill a sense of ownership.
Conduct user story writing workshops that are 2-4 hours in length.
Agile teams often track user stories on index cards pinned to a wall so that they can be moved around easily to different piles and processed using pull methods such as Kanban:
Additional piles can be created as needed. For example, during a spring a team may have piles for design, analysis, coding, testing. Individual developers may have their own piles. The piles of frequently managed using a Kanban board.
There are many software tools for tracking user stories which is particularly useful for distributed teams. Two such vendors are Rally Software and VersionOne.
User stories should encourage discussion rather than a focus on large, up-front requirements specifications.
User stories are not the same as use cases, but both serve a similar purpose: understand what the user needs.
| User Story | Use Case |
|---|---|
| Simple statement of user need and purpose for need | More complete definition of user need and how system is expected to behave |
| Elaborated through conversation on agile projects | Elaborated through step-by-step narrative scenarios |
| Defines acceptance criteria and scenarios | Defines pre and post conditions |
Both are augmented with models to specify expected behavior, but the models may not be formal work products or deliverables in an agile environment.
Some user stories might be larger or describe a more complex user need. Such stories are called epics. The general rule is that a story should be implementable in a single iteration timebox. An epic is decomposed into smaller stories. Epics are not sized. Epics fall into one of two categories:
Epics are eventually decomposed (broken down) into smaller stories, often using CRUD boundaries:
Epics can also be broken down by operational boundaries or data boundaries. Bill Wake suggests to “slice the cake” when confronted with large stories that can be implemented incrementally. For example, consider the story
“As a job seeker, I want to apply for a position.”
This story can be split into two increments:
However, while this might sound useful, it is important to only apply this technique when faced with stories that are too large, do not fit into a single iteration, or represent individually deployable functionality. Stories should represent single interactive transactions that have a short duration and can be completed in a single session.
For example,
“As a recruiter, I want to manage job posting”
is not something a user would complete in a single interactive session. This might be better broken up into these smaller stories:
In some cases, a story might need to implemented differently depending on the data being processed or rules applied. For instance,
“As a job seeker, I want to search jobs by applying filters”
could be decomposed into:
Often a story might implement an entire business process that takes substantial time to complete and might involve multiple users. To decompose such an epic, model the business process, and then implement each step in the process as a separate story. The decomposed stories will form a theme.
Themes are collections of similar stories that form some kind of a group.
Analysts often use the INVEST model from Extreme Programming to help write stories:
The lecture below by Dr. Schedlbauer summarizes user stories.
Slide Deck: S-90-301 User Stories
User stories are negotiable descriptions of features desired by a user representing business value to them. Large stories – epics – are decomposed into smaller stories to simplify estimation and implementation. Good stories should follow the INVEST model.
None.