A structured and practical introduction to writing a user story in agile project management.
The Scrum Process
In Scrum, requirements from the Product Backlog are converted into Product Increments during Sprint Cycles.
Levels of functional details
Requirements in Scrum are described as User Stories which can additionally be grouped as Epics and Themes.
Themes
A Theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific. At its most granular form, a Theme may be an Epic.
Example: Personalize user experience
Epics
An Agile Epic is a group of related User Stories, representing a feature. You would be unlikely to introduce an Epic into a sprint without first breaking it down into it’s component User Stories so as to reduce uncertainty.
Example: Allow users to create user profiles
User Story
A User Story is a description of desired functionality told from the perspective of the a specific role.
Example: As a registered user, I want to reset my password so that I can login into the site if I forget my password.
Task
Tasks are individual activities that are required for a User Story to be “done”.
Example: Write unit test script
A little more details on User Stories
In Scrum, User Stories describe the requirements to a product in a structured and compact format.
A User Story …
- is a basic unit of work representing some business value that can be delivered within a sprint.
- includes enough detail to enable the project team to make planning decisions.
- consists of one or more sentences used to describe user needs and act as a placeholder for a conversation.
- captures the “who”, “what”, and “why” in a simple and concise way.
- is used to describe requirements for different personas.
The difference between an Epic and a User Story: Whereas User Stories must fit into one Sprint, Epics usually span multiple Sprints. To create good User Stories, the INVEST method became accepted.
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable (vertical) | A user story must deliver value to the end user and represents a slice of vertical functionality. |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Scalable (small-sized) | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
Acceptance Criteria
A User Story can be enriched by describing acceptance criteria that relate to the outcome of the User Story.
Overview:
- Explains the Product Owner’s (PO) conditions of satisfaction.
- Provide a set of conditions that the story must meet to be accepted as complete by the PO.
- It is usually the minimum functional requirements for a given feature and allows the team to gain a shared understanding of a story.
- Helps a PO answer what is needed in order for a feature to provide value.
- Helps developers know when to stop adding more functionality.
- Helps testers know when testing the user story is complete.
Definition of Ready (DoR)
DoR is a set of agreements that lets everyone know when something is ready to begin (i.e., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint).
Definition of Done (DoD)
DoD is a quality checklist of activities, published by the team and agreed with stakeholders and the Product Owner, that must be completed in order for a User Story to be considered done.
We can support you with your project
ToBeConsult offers individually tailored solutions and no standard procedure. We have developed a structured approach, models and efficient methods and apply them in cooperation with our customers. We think entrepreneurially and always act from the owner’s point of view.