10. Techniques
10.48 User Stories
BABOK® Guide
10.48.1 Purpose
A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
10.48.2 Description
User stories capture the needs of a specific stakeholder and enable teams to define features of value to a stakeholder using short, simple documentation. They can serve as a basis for identifying needs and allow for the prioritizing, estimating, and planning of solutions. A user story is typically a sentence or two that describes who has the need addressed by the story, the goal the user is trying to accomplish, and any additional information that may be critical to understanding the scope of the story. With a focus on stakeholder value, user stories invite exploration of the requirements by promoting additional conversations with stakeholders and grouping functional requirements for delivery.
User stories can be used:
- to capture stakeholder needs and prioritize development of solutions,
- as a basis of estimating and planning solution delivery,
- as a basis for generating user acceptance tests,
- as a metric for measuring the delivery of value,
- as a unit for tracing related requirements,
- as a basis for additional analysis, and
- as a unit of project management and reporting.
10.48.3 Elements
.1 Title (optional)
The title of the story describes an activity the stakeholder wants to carry out with the system. Typically, it is an active-verb goal phrase similar to the way use cases are titled.
.2 Statement of Value
There is no mandatory structure for user stories.
The most popular format includes three components:
- Who: a user role or persona.
- What: a necessary action, behaviour, feature, or quality.
- Why: the benefit or value received by the user when the story is implemented.
For example, "As a <who>, I need to <what>, so that <why>." "Given...When...Then" is another common format.
.3 Conversation
User stories help teams to explore and understand the feature described in the story and the value it will deliver to the stakeholder. The story itself doesn't capture everything there is to know about the stakeholder need and the information in the story is supplemented by further modelling as the story is delivered.
.4 Acceptance Criteria
A user story may be supported through the development of detailed acceptance criteria (see Acceptance and Evaluation Criteria (p. 217)). Acceptance criteria define the boundaries of a user story and help the team to understand what the solution needs to provide in order to deliver value for the stakeholders. Acceptance criteria may be supplemented with other analysis models as needed.
10.48.4 Usage Considerations
.1 Strengths
- Easily understandable by stakeholders.
- Can be developed through a variety of elicitation techniques.
- Focuses on value to stakeholders.
- A shared understanding of the business domain is enhanced through collaboration on defining and exploring user stories.
- Tied to small, implementable, and testable slices of functionality, which facilitates rapid delivery and frequent customer feedback.
.2 Limitations
In general, user stories are intended as a tool for short-term capture and prioritization of requirements and not for long-term knowledge retention or to provide a detailed analysis. Neglecting this principle can lead to the following issues:
- This conversational approach can challenge the team since they do not have all the answers and detailed specifications upfront.
- Requires context and visibility; the team can lose sight of the big picture if stories are not traced back through validation or supplemented with higher- level analysis and visual artifacts.
- May not provide enough documentation to meet the need for governance, a baseline for future work, or stakeholder expectations. Additional documentation may be required.
