User stories in Scrum – Product Owner primer

By Nick Butler

Tags:

Team at a table discussing user stories in Scrum project meeting.

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.

Buy the Guide now


User stories in Scrum

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.

What are user stories?

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:

  • written from the point of view of the customer
  • in the language the customer would use.

Product Owners and user stories in Scrum

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.

Anatomy of a user story in Scrum

Here are the elements that make up a user story. Stories don’t start with all these elements, they get added as you go.

User story template for Scrum.

Name

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.

ID number

An optional unique ID, often assigned as you add the story to your digital story tracking tool.

Description of the customer benefit

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

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.

A team discuss acceptance criteria at a couch.

Tasks, notes and attachments

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.

Size

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.

Status

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.

You can record the status of user stories in Scrum by moving the story along a physical board like this one using post-its on a whiteboard divided into columns showing status.

Example user story

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

  • call to action content is displayed
  • user can subscribe by supplying their email address
  • user’s details are stored in a database
  • spam protection is in place
  • user gets a thank you message

Tasks, notes and attachments

Tasks:

  • implement call to action
  • embed javascript subscribe snippet from our newsletter tool button
  • implement spam protection
  • build thank you message

Notes:

Epic: Create Cinerama News page on website

Attachments:

Text for the call to action and thank you message

Estimation

M

Status

In progress

More examples

To see what makes an effective user story by comparing good and bad examples, you can get a set of user story examples here.

The stages user stories go through

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.

A team discuss user story tasks with post-its at a table. Conversation is one of the key features of user stories in Scrum.

The evolution of user stories through your Sprints

Here’s a brief outline of how this happens as you run through your Sprints.

Before the Sprint

Discovery

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.

Refinement

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:

  • make sure they are in priority order
  • add the description of the customer benefits to the stub
  • draft the acceptance criteria.

In the refinement meeting the Development Team will:

  • quiz you to clarify the story
  • discuss how they would complete it
  • review its priority
  • suggest changes so it meets the INVEST criteria
  • estimate its size.

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.

During the Sprint

Three Scrum Team members discuss user stories at a laptop.

Sprint Planning

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.

Daily Scrum

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.

Acceptance

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.

Review

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.

Retrospective

When you look back to identify ways you can improve, keep in mind if there are any opportunities to develop your stories more effectively.

INVEST in good user stories

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).

Pros and cons of user stories in Scrum

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:

  • focus on the benefit to the customer
  • minimise upfront effort
  • evolve as you learn more
  • make use of face-to-face communication
  • have a common structure making it easier to compare, prioritise and estimate stories
  • use language anyone can understand making them good for communicating with stakeholders.

Cons include:

  1. It can be hard to write them for backend or maintenance tasks.
  2. They can seem like a slightly casual way to capture requirements for people who are new to Scrum.
  3. The fact that you repeat the process means it can become a rote task. This can lead to people cutting corners.

To resolve these you can:

  1. Think of the ultimate benefit of these backend or maintenance tasks. You should be able to express this in your user stories. Mike Cohn gives a number of examples here.
  2. Using a template helps stakeholders see how the stories are structured, and showing them stories at the end of their evolution shows the level of detail they can capture.
  3. Vary how you do them, and who does what. Maintain the motivation by harking back to the vision, and how the stories are going to have an impact for the better.

The story of user stories

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?”

The Product Owner Primer

  1. What is Scrum?
  2. Six signs of a successful Scrum Team 
  3. Making multiple Product Owners work in Scrum: A case study
  4. Working with stakeholders in Scrum
  5. Product discovery for Scrum Product Owners
  6. User stories in Scrum
  7. The Scrum Product Owner role summarised

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.

Buy the Guide now


Agile training

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

Learn more

Find out more about writing effective user stories.

Make a bigger impact tomorrow

Talk to us today