One of the most important aspects of successful Agile delivery is having high-quality user stories. This will ensure the development team are able to focus on delivering value to users and the business. But what are the key elements to a user story and how are they constructed?
1. User Stories Must Always Have a User!
The first point might sound obvious. A user story needs to start with identifying who is asking for the value to be delivered. Who is the user that needs a feature delivered or a bug fixed? Work should not be done unless the user is known. This could be an actual user who has come to your team with a request, an external customer or a range of users the Product Owner is representing.
We structure the first part of the story as follows:
As a [USER NAME]……
Where [USER NAME] is the name of the user. Seems simple, but it’s vital the user is identified and explained to the team so that they can put themselves in their shoes and mindset when considering the best way to deliver value for them.
“As an iPhone user…” or “As a Senior Accountant…”
We sometimes even have the development team as a user if there is some work they have identified that needs to be done on the project that might be more on the technical side, but still, delivers value to the business or project.
2. User stories capture what the user wants to achieve in a simple sentence
The next element to the story is what the user wants. Do they want to be able to see a history of items they have ordered, or share a picture with their friends? Without this, the team don’t know what they are meant to be building in order to add value.
One of the common mistakes here is to write a solution down. User stories should not contain a solution. One of the skills a Product Owner needs to have is the ability to work with users to avoid jumping to solutions when capturing their requirements. It is natural human behaviour and the user will often try and present a solution based on previous experience or jump to an assumption. However, by doing this the best route to value delivery could be limited as the team are usually best placed to come up with the solution. Jumping to solutions deserves an article all to itself. One for another day.
So here is how we present this next key element of a user story, the user need:
As a [USER NAME]: I can [ACHIEVE SOMETHING]….
Examples:
“As an iPhone user: I can share photos I have taken with my friends”
or
“As a Senior Accountant: I can see results from the monthly sales activity”
Notice we don’t say “I can click on a button that will give me options to share photos from a gallery”, or “The monthly sales results need to be displayed on a red background and in a pop-up window”.
3. User stories contain a qualifying value statement
Within our team, we call this the “so that” part of the story. A user and the business wants value. It is important the team and Product Owner understands what that value is.
It is presented as follows:
As a [USER NAME] I can [ACHIEVE SOMETHING], so that [VALUE STATEMENT]
Examples:
“As an iPhone user: I can share photos I have taken with my friends so that we can decide on what colour to paint the new office”
or
“As a Senior Accountant: I can see results from the monthly sales activity so that I can be informed about our performance and make projections for the rest of the year.”
Without the value statement, it is much harder for the Product Owner to decide and negotiate on the priority of work to be done with one or more stakeholders. It also means that the team are unable to justify why they are doing the work in the first place.
A story shouldn’t be accepted unless it can be shown to deliver value to a user or the business. This includes the most technical stories requested by the team I have mentioned above.
4. User stories contain acceptance criteria
Think of acceptance criteria as a checklist of requirements that either flesh out the user need in more detail or add some criteria that give a specific measure or measures for the team’s output to be acceptable.
We write these as a bulleted list within the story.
Examples:
“As an iPhone user: I can share photos I have taken with my friends so that we can decide on what colour to paint the new office.
· I can select photos I have already got store on my phone
· I can share more than one photo at a time
· Sharing the photos takes no more than 1 second per photo”
Notice the list contains a mixture of criteria that include some functional detail (selecting photos already stored) and measurable criteria (sharing takes no more than 1 second).
The acceptance criteria are used by the team to inform their thinking in the technical design and are used by the Product Owner when it comes to signing off a story as being complete and ready to present to the users and ultimately ship.
It is tempting to put a lot of detail into the acceptance criteria, but try and keep them short and succinct like the examples above. Also, try not to have too many. If the list contains a lot of criteria you may be faced with a story that is too complex and needs breaking down into smaller stories.
5. User stories are small and simple
In order to ensure work is achievable within a given sprint cycle, stories should be broken down to be small enough to complete in this time period, whether it’s one week, a fortnight or longer.
If stories are too complex that’s a warning sign you need to see if they can be broken down into bite size chunks. This makes the work more accessible to the team and clearer for the business.
Sometimes we will break an 8 point story down into five 2 point stories. This can seem like more work at first glance, but by continuing to reduce down you will be much better off by increasing your chances of delivering higher priority value. In fact, we have often found that by breaking bigger stories down into smaller ones, we can often identify a part of the overall requirement that is not actually a priority and can either be moved further down the backlog or removed altogether saving wasted work.
A common practice in the industry is to ensure a story can only fit on a single index card.
Get your team’s agility and productivity score for free
I have created a free scorecard where you can get instant results on your team’s performance benchmarked against the very best. It takes just three minutes to complete.
Posted in:Agile
