What are User Stories?
You will here many different meanings for User Stories, but the one I like to use is: A User Story is a statement intended to identify a unique feature or a function that delivers some useful and valuable functionality to a stakeholder.
User Stories are intended to identify but not to define in detail. Once captured on a story card, the story represents a commitment to have a more detailed conversation at a later stage about what will need to be done to deliver this feature or functionality.
User Stories are a short (one sentence) description, written in an everyday and easy to understand way, on a story card and may be just one part of an overall story.
Here is an example of the user story format;
As a [Role], I want to [do something], so I can [achieve outcome]
Why Do We Write Stories?
The advantages of the story approach are:
- It encourages us to focus on what our stakeholders need and want
- It encourages us to use verbal communication, which has the benefits of richer and more immediate feedback
- It is easy for both the stakeholder and the team to understand the meaning of a story
- Stories provide enough information for us to plan and prioritise work
Who Writes the Stories and When?
Stories are written by the whole team and should involve the stakeholder or a stakeholder champion to make sure there is a true representation of the stakeholder’s needs and desires.
A facilitator may lead the discussion, however the whole core team will be involved in writing the stakeholder orientated stories.
Story writing usually happens very early on in a project when we are trying to establish the problem we are trying to solve or the opportunity we have before us.
How Do You Create Stories?
The first step in creating stories is to identify who your stakeholders are, grouping them can sometimes help if there is a large number to consider.
Take one stakeholder/group and identify the goals that they would want or need from the product or service you are providing.
Create a story for each goal following the format below.
‘As a [Role], I want to [do something], so I can [achieve outcome]’
A tool for measuring whether or not your story writing is correct is called INVEST.
INVEST stands for Independent, Negotiable, Valuable, Estimate-able, Small and Testable. A brief description follows:
Where ever possible stories should be independent from each other. Keeping track of dependences when planning and estimating can become very complex.
Negotiable means that the story is left with room for further discussion to expand on the details and how the story will be implemented. In other words; the story is not too detailed that it doesn’t allow for refinement later.
You should be able to understand the value of each user story. If a story adds no value to the stakeholder then the argument is that it should not be implemented. A story must be all about adding customer value.
User Stories must be able to be estimated. If it can’t be, it makes it difficult to plan and prioritise. Stories that are unable to be estimated are possibly too large or there is more learning needed to understand better.
When more research is required in this type of situation, it is often referred to as a ‘Spike’; a short, sharp piece of investigation.
A story should generally be small enough to finish in a single iteration. If a story has an ‘And’ in the ‘I want to do [Something]’ section of the story, this indicates that the story should be broken in two.
Whilst there can be more than one ‘achieved outcome’ from one story, there should only be one ‘something’ per story.
Testable, although very much an IT word, means that the feature being delivered needs to be tangible; there should be some way of judging if what was asked for, was created.
Think of this as a Definition of Done.
How Are Stories Used?
When the team gets together to have the discussion about the User Stories they will establish some goals and outcomes required to achieve value for the stakeholder.
They discuss the work that is involved in order to create this stakeholder value and how they will go about it.
Once they have established the work involved, the work is then ‘chunked’ into pieces, a brief description written on index cards and an estimation of complexity or size is appointed to each chunk.
These cards are then used to create a high level plan which we call a Release/Delivery Plan.
A Release Plan is made up of a series of iterations that span over a given period of time; an iteration being a cycle of work (often referred to as a Sprint in Scrum), typically 2-4 weeks in duration.
The chunks of work get prioritised and allocated to an iteration within the release plan. Care should be taken to evenly pace work, allocating only what the team would be capable of getting through in each iteration period.
To begin with you will not know what the team is capable of, however, after a few iterations this will become easier to assess.
At the beginning of each iteration the team meets to plan and task up the chunks of work allocated for that iteration. Work is broken down into achievable tasks that express more detail and are of a size that can be completed within an iteration period. Tasks are allocated to individual team members at this time.
Task cards are then placed into the backlog on the project wall, ready to begin the iteration. As tasks are commenced, the cards will move from back log into the ‘In flight’ section on the project wall and as they are completed, they then get moved to the ‘Completed’ column.