I have worked in many teams who define product and project requirements as user stories and acceptance criteria. What makes a good user story?
As a User I want to listen to a documentary programme from Radio 4 on my PC, so that I can increase my understanding of the subject of the documentary.
As an example, here is a bad user story:
I want to click on a ‘buy this’ link that adds the item to my shopping basket.
One of the easiest ways for us to assess a projects success during development is by using user stories and acceptance criteria. However, user stories seem to be very dependent on who has written them.
In my opinion, a good user story has the following characteristics:
- It defines Who needs this requirement met – for example the Product Manger, a Stakeholder, or the User.
If the team don’t know who the requirement is for, and we want to find out more about this requirement, who should we talk to? Knowing who is important, to help us get further understanding.
- It defines what is supposed to happen.
This is the surface requirement. Ideally there is some evidence, research or analysis to support this requirement. You might add this research as supporting notes for the story.
- It defines why it is supposed to happen – what is the benefit?
Defining why a requirement is important (the ‘So that’ part of the story) increases understanding of the underlying need, and can greatly help innovation.
For example, we know that in the above ‘radio 4 programme’ story, the goal of the user is to understand the subject better. Perhaps on the web, this can be accomplished in other ways than ‘listening to the programme’ (a solution might be simply providing some related links for the programme). If we just have 1/2 the story – eg ‘As a User I want to listen to a documentary programme from Radio 4 on my PC’ , without expressing why this is important, we miss the opportunity to innovate.
To further encourage innovation, I also try to remove any reference to how from a user story. Supporting notes for the story might suggest:
- When it is supposed to happen.
- Where it is supposed to happen.
- How it is supposed to happen – this is just an idea, but might be useful as inspiration for the team.
The keyword here is ‘suggest’. If we dictate the How and When and Where then we have weakened the project teams ability to innovate. If we were working on a factory production line, a lack of innovation can be useful (although Toyota seem to have done quite well through innovating on the production line), but if we’re knowledge workers working on a project, one of the outcomes should be some innovation.
Improving user stories
‘I want to click on a ‘buy this’ link that adds the item to my shopping basket.’
The above is a restrictive user story. Lets try and improve it.
Start by adding who it is for:
As a user I want to click on a ‘buy this’ link that adds the item to my shopping basket.
Now we know that if we want further information about this story, we should talk to user experience staff, or audience research staff. They may have further research that explains this story.
Now we can remove the how from the story. In this case the ‘buy this’ link is defining how the story is to be implemented. Removing this we end up with:
As a user I want to add items to my shopping basket.
This shopping basket idea might be well understood, but we would do well to define its behavior better, just to be sure we will get what we want. The shopping basket concept has several features that are worth considering separately.
The underlying function of adding items to a shopping basket is to collect all items I want to buy in one place, so that I can review all my proposed purchases and pay for them all at once.
As a user I want to collect all the items I want to buy, together in one place, so that I can review my proposed purchases and organise payment and delivery details for all of my shopping just once.
If we add a note to this user story ‘The one place that collects all items together might be a ‘shopping basket’ then we’ve explained our idea, but also left it open to design staff to think about other solutions that satisfy the same story. For example, they might think about storing previous payment and delivery details, so that repeat visits to the site are even easier.
The other aspect of the basket is being able to add, remove and change the quantities of items I have collected, before I purchase them.
As a user I want to be able to add, remove and change the quantities of items I want to purchase without journeying back to each individual products page, so that it is easy to complete my shopping.
So now we have 2 user stories, but a clearer definition of the basket functionality, and a clearer definition of the underlying needs of the user.
Great user experiences (I’m going to say it, sorry) for example, those delivered by Apple, are partly successful because they have worked hard to answer not just the surface requirement, but the underlying need. Great user stories are the foundations on which experiences are built. Making sure those stories are solid, researched, and prescribed appropriately for the project aims is very very important. By making sure that a user story defines who, what and why we have the basis of a good story.
Keeping how out of the story gives a project important room to innovate.
Thanks for reading – let me know your comments.