First things first: User Story is not an alternative name of the Product Backlog Item.
| Product Backlog Item | User Story |
| A reference to a capability, feature or anything we want to have in our product. | A requirement capturing technique, originally invented for eXtreme Programming. |
| It should have a title, estimation, value and rank. | The user story can have any format, though typically formulated with the following template: ‘As a {…}, I want to {…}, in order to {…}. It is often enriched with acceptance criteria. The template is rarely enough for expressing a complex requirement. |
| Once it is “Done”, it is done. Part of the product. | Requirements change, so do user stories. This may induce a new body of work. |
Let’s see the details!
The main point of agility is to improve the organization’s ability to respond to change and opportunities. Complex, heavy-weight upfront documentation does not support this goal. In the agile world, requirements are expressed in small and manageable pieces, usually in the form of user stories. The user story is regarded to be the smallest unit of a business goal which cannot be further decomposed.
Due to its size, a user story is an ideal way to represent a product backlog item. User stories should be as much as possible self-contained, represent value on their own, and should have minimal dependencies on other stories. This gives the freedom to the product owner (or the person in charge) to change, replace, drop user stories without initiating a dragging change request process.
The Format of a User Story
Traditionally a user story should have a role or actor, a goal, and a benefit:
As an [actor]
I want to [perform an operation]
in order to [gain benefit].
For example:
As a system administrator
I want to provision forgot password functionality to my users
in order to get rid of password reset requests.
If a story is added to a product backlog, it is a good idea to give it a title. The title helps the quick visual identification of a product backlog item, making product backlog management more convenient. In the above example ‘Forgot password’ would perfectly identify the story. It is good the keep in mind that stories are often represented by cards (or simply ‘sticky notes’) where the space for text is limited.
Depending on the nature and phase of a delivery process, the length, detail and format of user stories may vary. As long as high-level business requirements are discussed, the above format is just enough. When a specific solution is defined, however, more and more details might be required. Roles, for example, become standardized, e.g. stories can only use a given set of personas or planned system user roles. Spoiler alert: complex business software e.g. a credit account management system cannot be defined through user-centric stories. For more complex requirements it would be practical to add a detailed description, explanation, process maps, data models, examples, etc. Acceptance criteria can help to understand, validate and verify the requirements. A user story may even contain use cases if a team values this type of structured documentation.
The Size of a User Story
When a user story is a product backlog item, it needs to be detailed enough for facilitating estimation. Estimating a story is the privilege of the teams/individuals implementing the solution, thus the story must be specific and descriptive to the extent so that technical experts can draft their implementation solution. In Scrum, a story should have a size that fits a single sprint. If it is bigger, we may call it an epic (the parallel with literature is apparent, an epic is a long series of stories, even though in Agile usually not in quantitative verses). The Product Owner has to break down the epics into smaller stories. Other agile approaches may use different measures to limit the size of a story, however, the underlying goal is the same: reducing risk and complexity.
Ideally, stories should have a ‘definition of ready’, which helps to identify whether a story is detailed enough for implementation. In large organizations, this may require approval from stakeholders and technical teams. Otherwise, the product owner may simply decide when a story is ready.
Techniques for Writing Good User Stories
The three C’s
The term was introduced by Ron Jeffries to describe the technique for managing user stories: Cards, Conversation, Confirmation.
- Cards refer to the representation of a story on a Kanban board.
- The conversation should take place between the technical and business teams in order to elicit the user story in depth.
- Confirmation is the end of the story (literally), meaning that the objective has been met.
I.N.V.E.S.T.
INVEST is an acronym created by Bill Wake to recall the characteristics of a good user story:
- Independent, thus can be implemented on its own and outcome will be fully functional,
- Negotiable, thus leaves room for implementation ideas, finding the best solution for the user,
- Valuable, thus should give reasonable value to the user,
- Estimable, thus we can guess the difficulty and of the implementation,
- Small, bearing little risk and fitting into a single a Sprint,
- Testable, thus, it will be possible to determine whether the implementation is fit for purpose.
The Three Amigos
The three amigos refer to specification (what we need), implementation (how can we implement it) and testing (how can we verify this). The three amigos represent three different viewpoints of the same problem and contribute to apriori learning about a business problem.