The attributes of a good user story.
In the simplest terms a user story is the means for delivering change to an application. To this end they are intended to be independent and self-sufficient. So they will typically cover every phase of the delivery life-cycle. To successfully do this a user story needs the following attributes:
- Number
- Title
- Narrative
- Problem statement
- Dependencies
- Status
- Points
- Priority
- Value
- Acceptance criteria
- Tasks.
The number is a unique number to identify the user story within a backlog or organisation.
Title describes the user story to help find it in a list or on a wall.
Narrative is the high-level requirement of the story. These are always written in the format of ‘as a .. I want .. so that..’. The ‘as a’ describes the user who will benefit from the user story. They are sometimes referred to as the actor. You often see narratives that start with ‘as a product owner’. These somewhat miss the point as they are not written from the users perspective but instead from that of whoever is typically providing the requirement. The idea is that these are written from the users perspective so they describe the users interaction with the system and the benefit that it then provides to them. E.G. as a customer I want to enter my personal details and information about the car that I want to cover so that I can get a quote for car insurance.
Problem statement allows the author of the story to provide further details to guide the next phases of the story delivery. This will typically include contextual information for the user story and some more detail around the requirement. A good way to write a problem statement is to answer the following questions:
- What is the current functionality that I want to change?
- What is the ‘to be’ functionality?
- What issues does the current functionality have?
- How might I solve this problem?
Dependencies are a fact of application development. Although there is a theory that there should be no dependencies between user stories this is rarely the case, especially during initial application development of a minimum viable product. For example in any insurance system you cannot play user stories that are to cancel a policy until you have first completed the user stories that enable you to purchase it. Consequently where there is a clear order in which user stories need to be played then this should be captured as part of the initial story definition.
Status of the user story is used to define where in the delivery process the user story currently resides. Typical values for user story status include:
- Draft – Created.
- Accepted – All acceptance criteria are complete and agreed.
- Ready – Solution design is complete and reviewed and all build tasks identified.
- Done – User story is completed and delivered.
Points are used to measure relative user story size. The points score does not equate to a specific number of man days exactly but it does equate to the relative amount of effort needed to deliver that user story. Consequently any two user stories with the same points score should require the same amount of effort to deliver. Also if we have a three point user story and a two point user story and a one point user story then there should be as much effort to deliver the three point user story as to deliver both the one and two point user stories. The number of points that can be selected for a user story typically follow one of two sequences. These are:
- 1,2,4,8,16,32,Epic
- 1,2,3,5,8,13,21,Epic
The reason for using these points values is to recognise that as an estimate gets larger then it becomes less accurate so the lack of granularity between the numbers are used to reflect this. Also it is worth noting that these lists do not get very large. This is because a user story should be completed within an iteration so where a user story is too large to fit it is described as an epic. Where you have an epic user story then the goal is to break it down into smaller user stories. This is similar to how you might take a high-level requirement and then break it down into child requirements with further detail.
Points are used to calculate the velocity of a team. Velocity is the total number of points that a team can deliver in a fixed length iteration. Understanding this number is used to predict how long a project will take to deliver.
Priority is used in the initial categorisation of a user story as it is a lot quicker to determine than a value score. MoSCoW (Must have, Should have, Could have, Would like/Won’t have) are used to quickly sort user stories and to determine the minimum viable product (this should be all the must have user stories).
Value is the business benefit of delivering the user story. We use a term called relative value when choosing a value amount for a user story because we want to allow the business to use whatever method makes most sense to them to determine what the value of the user story is. This can be anything from a business benefit expressed as an annual income to prevention of a fine or to ensure adherence to an organisational value.
Acceptance criteria are in their simplest sense used to determine if the user story has been completed. If the all acceptance criteria have been met then the user story is complete. There are a number of different ways to define acceptance criteria. These vary from a definition of the changes required to the application to deliver the narrative to a comprehensive set of test cases that will demonstrate that the user story has been delivered. Both are required to successfully complete a user story with one being a step to the next. This is because it is difficult to think of all of the tests that are required to prove that a user story is complete without first identifying the changes that are required to the application that you need to test.
Tasks are the actions that must be completed by the backlog team to complete the user story. Some typical tasks are shown below:
- Write acceptance criteria
- Identify system changes
- Set up test environment
- Create automated test cases
- Make code changes
- Execute tests
- Migrate code changes…
The tasks in a user story are typically managed through the daily stand-up.
Story Card
Story cards are the basic tool for agile projects that allow users to manipulate and brainstorm efficiently. Typically these can be used on a project story wall to show progress and also used in iteration planning meetings to determine order of delivery through the iterations. The following diagram shows the salient information to place on a story card:
