Simple steps for writing better user stories for you and your team.
I want to…
Although the above may seem odd to the unfamiliar eye, it is not a weird word association game or a bizarre version of Twister, blindly putting parts where you think they should go and hoping the next step doesn’t end with you falling into a muddled heap (we've all been there).
It is a template for a user story; an agile approach to the requirements a designer or developer should focus on in order to deliver a product that doesn’t have any hidden surprises for the client.
When I first started using Jira (the project management tool we use here at Brightec) to help manage user stories, I had no idea how to break down the mammoth briefs for a project into manageable tasks that made sense.
We'll look at Jira in more depth later, but a key turning point in my understanding of what a user story is was the idea of thinking of them as a placeholder for a conversation.
I came across a helpful blog by Jon Westernberg in which he discusses the importance of simplicity. One particular sentence stuck in my mind; ‘ Simple is beautiful because simple allows you to communicate’.
When I applied this to writing a user story, the pressure (and fear) I felt of omitting something important to the app was removed. I was reassured that the story was there to remind the assignee about a specific functionality or requirement, not to provide every possible minuscule detail.
If you are familiar with user stories you may be used to working with Epics. As we are an agency we tend not to work with Epics, essentially what we work on is a client’s epic and we complete the workflow to achieve their goal.
The first step is to write a criteria; the ‘I want to… ’ part, which comes from asking the client questions.
I’ve also learnt its ok to do that, in fact, clients love it. It provides reassurance that both sides are clear on what will be delivered and the opportunity for them to talk about the idea they are passionate about. The criteria must be agreed on before coding starts.
Criteria should be specific (what will make the story successful), measurable and realistic. A useful ‘tool’ is INVEST - Independent, Negotiable, Valuable, Estimate, Small, Testable.
Next, a story needs a role, a group of users with a need.
For example; the user (target audience), owner or developer; this is the, ‘As a….’ part. Yes, I know it seems backwards to write the first bit of a user story last!
A story also needs a persona. This is different to a role, the persona provides a backstory for the role and identifies the user’s motivation for using the app; the ‘So that...’ part.
Designers also use personas when creating the look, feel and flow of the app, so it’s helpful to use these company-wide.
Using Jira, the description is where the requirements to meet the customer expectations of each user story should be written. It should fill in the gaps left by the story.
The acceptance criteria, a list of the steps that need to happen to complete the story, are the basis of this section.
If a story is too big, the team could feel uncomfortable (like how I feel a bit sweaty and panicky trying to understand what to pick out of a client’s brief to write the user stories).
This uncertainty makes them less confident in their ability - never a good place to start a project.
A great way to overcome this is to split a story. Benefits of doing this include:
Splitting '3rd party' stories
It is also worth considering splitting anything dependant on a third party into its own story, so that the task can be done with a placeholder and polished when the dependency becomes available.
Splitting 'unknown' stories
When it comes to an unknown it could be useful to break it into two stories. One story to investigate (eg. As a developer, I want investigate … so that I can understand what is required) and the second story to carry out the work.
This makes it more manageable whilst also avoiding the possibility of the designer/developer becoming demotivated by working on that same task for too long, feeling like they aren’t making any progress.
It can be a struggle understanding the difference between ‘code review’ and ‘done’. Surely if it is being reviewed it is technically done?
Getting to ‘Done’ means the expectations of the team and the customer have all been met. For the team, that means high-quality code, unit tested and peer reviewed. For the customer, it means they have an easy to use app that doesn’t crash.
Ultimately, a user story should be brief. And it can be changed!
Josh has written a great couple of blogs which go into more detail about how we work with agile methodology as well as tips to introduce your clients to user stories and how to implement them.
Search over 300 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!