By Nick Butler
Tags: Agile
This installment of the Product Owner Primer shows you how to best make use of user stories in Scrum. You’ll get a user story template, learn how Product Owners work collaboratively to develop user stories, and see what makes a good user story.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
The Scrum Guide doesn’t mention user stories. There’s the Product Backlog, the prioritised list of everything that is known to be needed in the product. And there’s the individual entries on the list, the Product Backlog items. These lay out what the Scrum Team will build.
These Product Backlog items could be things like requirements, use cases, specifications, bug fixes or maintenance tasks. But most Scrum Projects opt for user stories because they are a great way of keeping the customer front of mind and helping Product Owners maximise the value delivered.
A user story in Scrum is an evolving description of something your customer will do when using your product. At its heart is a short statement of the benefit your customer will get. This is:
Because the Product Owner is responsible for the Product Backlog, you are also responsible for the user stories.
While you make final decisions about the stories that go into the Backlog and their priority, you work with stakeholders to make these decisions and the Scrum Team to get the stories to the point they can build the benefit or feature into the product.
You don’t need to write the user stories, you can get the team to help you. To do this you need to make sure they are visible and available, often on a physical board and a digital tool like CA Agile Central (formerly Rally) or PivotalTracker.
Here are the elements that make up a user story. Stories don’t start with all these elements, they get added as you go.
Also known as the stub, the name is a clear, concise, specific label. Pick a name that will make it clear what story you’re referring to when you’re discussing your stories.
An optional unique ID, often assigned as you add the story to your digital story tracking tool.
A simple statement of the story’s who-what-why, using this structure:
As [actor] I want [action] so that [achievement].
The actor will usually be one of your user personas. This makes sure you have a good idea of who you are completing the user story for.
The action describes what will happen. It doesn’t describe how it will happen because that’s the domain of your Development Team.
The achievement explains the benefit the actor receives from the action. It shows why they want the action to take place and conveys the value of the story.
Acceptance criteria define how you’ll know the story has been completed. These help the Development Team because they give more detail about how they’ll deliver the benefit to your customer. And they help you as Product Owner because they show what you need to look for when you’re checking the work.
Learn more about acceptance criteria for user stories.
Tasks are a breakdown of the steps needed to complete the story. The team come up with and record these. Notes might include whether the story is part of an Epic, any dependencies and so on. The team can also ask the Product Owner to attach things like wireframes, workflow diagrams, use cases etc to the story.
This is the Development Team’s estimate of the relative size of the story. It ensures they get a shared understanding of the effort and complexity in each story and lets them judge which stories they’ll commit to completing in a Sprint.
We’ll look in more detail at how they do this in a later post.
What stage is the story in its journey from ‘not started’ to ‘done’? You might record this by moving the story along a physical board or by updating it in your digital tool.
Imagine you’re building a movie theatre website. Here’s one story you might have:
ID number
0032
Name
Subscribe to the Cinerama newsletter
Description of the customer benefit
As Mandy Moviebuff I want to be able to subscribe to the Cinerama newsletter so I can get excited about the upcoming attractions, competitions and offers at my favourite movie theatre.
Acceptance criteria
Tasks, notes and attachments
Tasks:
Notes:
Epic: Create Cinerama News page on website
Attachments:
Text for the call to action and thank you message
Estimation
M
Status
In progress
To see what makes an effective user story by comparing good and bad examples, you can get a set of user story examples here.
User stories sit in the priority order you as Product Owner gave them in the Product Backlog. User stories start simple and get more detailed as they move up the priority list, getting closer to being built. That way you don’t waste effort elaborating user stories that you later learn are not needed.
Ron Jeffries described the three critical elements of user stories as Card, Conversation and Confirmation, and Jeff Patton has extended these into a five-stage loop:
Card: Write the outline of your story idea on a card (or add it to your digital tool).
Conversation: Discuss how it will be achieved with the Development Team.
Confirmation: Agree on the approach and how you’ll all know it’s done. Note this as the acceptance criteria.
Construction: The Development Team build and test the user story as part of the Sprint Increment.
Consequences: Show it off and see what you can learn from it.
Here’s a brief outline of how this happens as you run through your Sprints.
User stories start as a brief statement of a user need that you’ve identified in your product discovery work. Maybe you ran a User Story Mapping exercise. Or perhaps you’ve learnt something new about your customers’ needs from a previous Increment. Often the user story will just be a stub — a brief, meaningful label.
As Product Owner you need to make sure that the stories at the top of the Backlog are ready for refinement.
Before your refinement meeting:
In the refinement meeting the Development Team will:
Here are a few handy prioritisation and estimation techniques.
You add the results of these discussions to the story. You may want to spell out what a refined story looks like with a Definition of Ready.
In this meeting the whole Scrum Team plan what you’ll achieve in the Sprint, and how you’ll achieve it. The more you’ve done in Refinement, the easier your Sprint Planning will be. This gives your Development Team more time to work out how they’ll do it. Having discussed it in refining and estimated its size they can make the call about whether they can commit to adding it to the Sprint Backlog.
As they coordinate the day’s work at the Daily Scrum, the Development Team will note progress made on stories, their next steps and anything that’s stopping the work so that these blockers can be resolved.
When the story is done, the Development Team will let you know the story is ready for you to check if it meets the acceptance criteria.
At the review the Development Team will demonstrate all the completed stories in action.
You’ll probably have stakeholders at the Review. They won’t have been involved in the whole conversation about the story so you’ll need to explain why the story was a priority and what it achieved. Luckily the benefit statement sums this up in a simple description!
Feedback you get from the Review, and from what you learn from getting the new Increment in front of your customers, may suggest you need a new story or changes to existing one.
When you look back to identify ways you can improve, keep in mind if there are any opportunities to develop your stories more effectively.
You can remember the criteria for good user stories through Bill Wake’s INVEST formula. User stories in Scrum should be:
Independent: The story doesn’t rely on other stories getting done. If stories are heavily dependent it’s hard to plan, prioritise and estimate them. You can often solve this by breaking up stories differently or grouping them together.
Negotiable: As Product Owner you draft your user story card to start a conversation with the Development Team, not to detail exactly what they’ll do. And the story may evolve as it gets developed.
Valuable: The story needs to spell out how the work will benefit your customer. When you’re thinking about this, keep in mind how it helps you achieve the Product Vision and Strategy you came up with in discovery.
Estimable: If the card and the conversation don’t give the Development Team enough information to estimate the size of the story, they can’t pull it into the Sprint.
Small: You should be able to complete your stories in one Sprint. Otherwise it can’t be part of a potentially releasable increment.
Testable: You need to know what you’re going to test when the Development Team send it to you for acceptance.
Learn more about the INVEST criteria and why each of them matters. You can also learn how to keep stories in line with the INVEST criteria in this post on Reducing batch size (keeping them Small) and this post on Reducing work in progress (keeping them Independent).
Understanding the benefits of user stories in Scrum helps you make sure your stories give you these benefits. And knowing the downsides helps you mitigate them.
Pros include the way that user stories:
Cons include:
To resolve these you can:
The origin story of user stories reminds us that they’re all about the excitement of delivering products customers love.
Kent Beck told Jeff Patton that he came up with the idea of user stories when he was thinking about the stories users tell about cool ways software helps them out:
“I type in the zip code and it automatically fills in the city and state without me having to touch a button!”
“If you can tell stories about what the software does and generate energy and interest and a vision in your listener’s mind,” Beck said, “then why not tell stories before the software does it?”
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
In New Zealand and keen to get to grips with Scrum and the Agile mindset? Check out our Agile training:
Agile Professional Foundation certification, Wellington, NZ – two-day ICAgile course
Introduction to Agile methodology, Wellington, NZ – free two-hour workshop
Agile Accelerator team assessment – Agile review and action plan
Find out more about writing effective user stories.
