Skip to content

7. Techniques

7.21 User Stories

Agile Extension to the BABOK® Guide

User Stories are used to convey a customer requirement for the delivery team.

User Stories are described in detail in the BABOK® Guide: 10.48 User Stories. The Agile Extension to the BABOK® Guide builds on the information in the BABOK® and describes how User Stories are applied in an agile context.

User Stories are a representation of the customer need and are expressed as a small, concise statement of a feature needed to deliver value. User Stories facilitate the interaction and collaboration of stakeholders.

The user story expresses a customer need and value desired. Typically, they are one or more sentences written by the customers, product owners, or business analysis practitioners which describe something of value to a stakeholder. User Stories provide a mechanism for the product owner to scope, coordinate, and prioritize the increments of user value for delivery. A user story is captured on the backlog.

User Stories represent stakeholder needs using short, simple documentation and invite exploration of the requirements through conversations, tests, and supplemental requirements representations as needed. They are concise and easy to change as stakeholder needs are better understood or as those needs evolve.

A commonly used construct for ensuring quality in user stories is the INVEST criteria, which calls for user stories to be:

  • (I) Independent: : represents a feature which can be delivered independent of other features.

    • Example: "ATM PIN entry" is independent from 'Withdrawal Amount'

  • (N) Negotiable: : the team can negotiate how to deliver.

  • (V) Valuable: : expresses the value to the customer.
    • Example: "ATM PIN entry" allows only the correct person to access the account.

  • (E) Estimable: : team can estimate effort to deliver based on past experience.

  • (S) Sized Appropriately: : for the team to complete in one iteration. In general, the smaller the better.

  • (T) Testable: : can be validated objectively by a stakeholder.

Not all backlog items are to be written as user stories. However, User Stories is a common technique used as they emphasize the customer value.

User Stories follow the 3Cs:

  • Card,

  • Conversation, and

  • Confirmation.

.1 Card

Title (optional)
The title of the user story describes an activity that the user wants to carry out with the solution. Typically, it is an active-verb goal phrase, similar to the way use cases are titled.

.2 Format

There is no mandatory structure for user stories; however, the most popular format includes three components:

  • a user role or persona [WHO],

  • a necessary action, behaviour, or feature [WHAT], and

  • the benefit or business value received by the user when the story is implemented [WHY].

Example format 1
"As a <role>, I need to <feature> so that <goal or value>."
As a current bank account holder, I need to access my account, so that I can withdraw cash.

Example format 2
"In order to <business value>, as a <role>, I need to <behaviour>."
In order to withdraw cash from my account, as a current bank account holder, I need access to my account.

.3 Conversation

The intended purpose of User Stories is to communicate between stakeholders and the delivery team. The user story intentionally does not capture all there is to know about the customer need. A well-written user story invokes conversation among the team.

.4 Confirmation

Business analysis practitioners confirm the delivered item satisfies the need expressed in the user story. This is most often expressed as acceptance criteria. Acceptance criteria define the boundaries of a user story and help verify and validate the solution met the intended user need.

Acceptance criteria help the delivery team identify the minimum amount of function necessary. Acceptance criteria are primarily used by the product owner and stakeholders to verify and validate. They also serve as a basis for acceptance tests, regression tests, exploratory tests, and other tests to be developed in support of the product.

.5 User Story Management

There are a variety of ways in which user stories are used throughout an agile initiative. The follow techniques are all impacted by User Stories:

  • 7.1 Backlog Refinement

  • 7.10 Product Roadmap

  • 7.18 Story Decomposition,

  • 7.19 Story Elaboration, and

  • 7.24 Visioning

.1 Strengths

  • Tied to small, implementable, and testable slices of functionality facilitating rapid delivery and frequent customer feedback.

  • Easily understandable by stakeholders.

  • Can be developed through a variety of elicitation techniques, including but not limited to facilitated workshops, contextual inquiry, and other ethnographic elicitation techniques.

  • User Stories are simple enough that people can learn to write them in a few minutes, being careful about always delivering business value.

  • The process of collaborating on defining and exploring stories builds team commitment and shared understanding of the business domain.

  • User Stories invite conversation for further decomposition and exploration.

  • To facilitate estimating, planning, and delivery, many agile teams supplement User Stories with analysis models (such as a data model, business rules, user acceptance tests, screen mock-ups or prototypes, context diagram, and state diagram).

.2 Limitations

  • This conversational approach can challenge the team, since they do not have all the answers and detailed specifications upfront.

  • Too many stories can inflate the backlog.

  • User Stories spawn more User Stories through decomposition, so the information must be organized to ensure it is current and relevant.

  • The collection of User Stories needs to be regularly refined and prioritized.

  • Teams can get too focused on individual User Stories and lose sight of the vision and product roadmap.

  • This technique includes the desired feature. Teams can form habits overlooking the value statement (WHY) and instead focus on the feature (WHAT).