Provide a summary of this practice.
User Stories are the basic unit of Agile work and delivery.
What is the overall goal or intention of this practice?
User Stories are used throughout the delivery cycle:
What are the schedule, cost, quality, performance or other expectations for completing this practice?
What must have happened or been delivered for this practice to be considered complete?
A story has completed its lifecycle when working software has been created that meets all the criteria identified in the SLA.
What pre-conditions must be met before this practice is used?
N/a: Stories evolve continuously, from high level ideas and aspirations to detailed definitions.
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Define the story.|
|3||Create a Spike|
|4||Agree acceptance criteria.|
|5||Validate story quality.|
|1||Define the story.||Developer.|
|Draft story.||Any team member may prepare stories.|
Stories are written in user language, not technical language.
Stories should use the Actor-Description-Benefit format:
Note that ‘As a user’ or ‘As a manager’ is usually too weak a definition of the Actor segment. Try to specify specific roles that explain why they want this specific function or have a specific benefit in mind.
Any of these items can be elaborated to any degree, limited only by:
For further advice on how to write stories, click here.
For tools for documenting stories, click here.
|2||Story clear?||Team.||If the story involves new stakeholders, review Manage stakeholders|
|3||Create a Spike||Developer.|
|4||Agree acceptance criteria.||Team.|
|Acceptance criteria.||The team as a whole must agree the Acceptance Criteria, because:|
Acceptance criteria are a key element of a story, as they focus development on explicit, testable needs.They take the following form:
|5||Validate story quality.||Iteration Lead.|
|Finalised story.|| A widely used set of story quality requirements is the INVEST model:A story should be:|
Issues and risks
What are the key concerns in making a success of this practice?
- For more on stories in general, click here.
- Historically Agile stories were thought of as specifically user stories. This may be too narrow a conception, and other kinds of story should also be included.
- The story format does not suit all user needs.
- Where the real users of a system cannot speak for themselves.
- In such circumstances, alternatives such as Feature-Driven Development (FDD) should be considered.
- Once the backlog has been populated with agreed features, it can be assigned, managed and implemented in the same way as a story-based backlog.
- Sometimes it isn’t realistic to elaborate needs during the development process:
- Detailed technical or regulatory specifications aren’t well communicated by informal discussion.
- Stories affecting multiple customer or user groups may need extensive agreement.
- Not all ‘stories’ are stories at all.
- Statements like ‘Must support peak load of 15,000 concurrent users’ or ‘98% availability’ are constraints, not stories.
- Being asked to clone an existing system, function or capability isn’t a story either. Ask what the story is which the copied item is supposed to support: exact copies rarely make much sense!
- Such items need to be taken into account when evaluating stories or developing the system, and should be carefully recorded and analysed for their impact.
- Stories are not equivalent to formal requirements. If you are inclined to think that they are, click here.
- There is no standard way of including non-functional requirements in a story. For example, you could include them:
- in the Acceptance Criteria.
- in the story’s Definition of Done (especially if they are shared with other stories).
- in tests.