← Back to The Checklist

User Stories in the Sprint Backlog are pulled from the Product Backlog. They list individual work items with generalized tasks that the working team can understand to complete the work.

The tasks are not intended to list out every little detail but instead to make the development team's User Stories usable/understandable.

Table of Contents

Developing User Stories can be accomplished in many ways. Examples include the INVEST or WWW models.

Writing a User Story

Nobody is sure why, but when it comes to writing a User Story (or any backlog items), we all tend to forget our creative writing skills (guilty). Because this is true more often than not, I never go it alone. I use primers, walk-throughs, or hints. Why make it difficult if you needn’t? Here are some excellent examples of what/how to write your user stories.

Keep it Simple

Roman Pichler’s 10 Tips for Writing Good User Stories post reminds us to keep our stories simple and concise [insert a knife-hand here]. Here’s his take on the simplicity of the ordeal:

10 Tips for Writing Good User Stories

As [persona], I want [what?] so that [why?].

Super simple, ‘eh? Remember, the user story won’t be an essay on the feature we’re trying to create; it’s meant to be a memory jogger for the Development Team to complete their task to the Definition of Done. How they get there is the Agile journey.

An Informal Thing

A user story is an informal, general explanation of a software feature written from the perspective of the end-user or customer. They don't go into detail. Requirements are added later, once agreed upon by the team.

Atlassian (from whom that great image and some explanation below comes) has a similar formula to write the User Story,

As a [persona], I [want to], [so that].

via Atlassian

• "As a [persona]": Who are we coding this feature for? Jack. The Development Team must have a shared understanding of who Joe is; how does he work, think, or feel? Will we cry at his wedding?
• “Wants to”: Here, we’re describing their intent — not the features they use. What’s Jack trying to achieve? This statement should be implementation free — if you’re representing any part of the UI and not what the user goal is, you're missing the point.
• “So that”: how does Jack’s immediate desire to do something this fit into their bigger picture? What’s the overall benefit he may be trying to achieve? What is the big problem that needs solving?

For example, user stories might look like this:

• As Jack, I want to tell my family I’m getting married so that we can enjoy this occasion together.
• As Ellie, I want to organize my stuffed animals to feel more in control.
• As a manager, I want to understand my colleague’s progress to better report our successes and failures.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end-users in the traditional sense; they can also be internal customers or colleagues within your organization who depend on your team.

Here are some other models to consider (just to make you smarter) when writing a User Story (or your Tasks).

INVEST Model