User Stories: What They Are and Why and How to Use Them
Agile 101
Agile Methodologies
Agile Practices
Agile Metrics
Agile Artifacts
Scaled Agile
What Is a User Story?
In Agile a user story is a short, informal, plain language description of what a user wants to do within a software product to gain something they find valuable.
User Stories: An overview
Soooo. User stories. You know stories. You’ve grown up with them. Like we all have. Stories and storytelling have a looong track record in human history.
But user stories? What’s that all about?
Well, let’s have a closer look at them. What they are, and why and how you use them in Agile development.
What Is a User Story?
In Agile a user story is a short, informal, plain language description of what a user wants to do within a software product to gain something they find valuable.
User stories typically follow the role-feature-benefit pattern (or template):
-
As a [type of user],
-
I want [an action]
-
so that [a benefit/value]
As the smallest unit of work in an Agile setting, user stories are a key tool in incremental development.
Why Use User Stories? What Are Their Benefits?
With user stories you put users at the center of the conversation around what to add to or change in a software product. They are the embodiment of the first principle behind the Agile Manifesto (emphasis mine):
With user stories you give a development team the context and the why of what they’re creating. Doing so helps them understand how they’re providing value for the business and to keep the user/customer top of mind.
User stories provide the essence needed to prioritize them.
There’s no need to add details such as requirements until you decide now’s the time to implement them. Apart perhaps from what Mike Cohn calls conditions of satisfaction with which a user can expand and explain concepts. You add other details as you get closer to implementing the story. For example, during the exploration phase in Behavior Driven Development (BDD).
The brevity allows you to change your mind until the last possible (responsible) moment without throwing away a lot of effort. This helps you with the second principle of the Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
The concise nature and user-focus of user stories also helps in separating who deals with what you’ll make (customer or product manager) and who deals with how you’ll make it (developers).
And finally, because user stories are small self-sustained units of work, you’ll enjoy lots of small wins as you complete one after the other. That’s good for building momentum.
How Not to Benefit From User Stories – Common Mistakes?
Common and classic mistakes working with user stories are:
-
Starting from a requirements document created in a non-Agile way and ending up with contrived stories.
-
Adding details and requirements too soon. Stories about to be implemented need the greatest level of detail and clarity. Stories coming up soon can do with less. And stories more than 2 or 3 iterations out don’t need any.
-
Not having a conversation about the story with everyone concerned, customers, users, developers, testers, business professionals, before you start implementation. This conversation is essential to collaboratively add the details, the acceptance criteria, that’ll prevent rework.
What Is a Good User Story?
-
Independent. You want user stories to be independent of each other so you can freely move them around your product backlog as priorities shift.
-
Negotiable. You lay down the details of a user story in collaboration between your customer and the team that’ll implement it. This collaboration includes negotiating the scope: what the implementation will and won’t include.
-
Valuable. A good user story has value to the customer (which may be an internal user). Without that value, there’s no point in putting any effort into the story.
-
Estimable. If you can’t estimate a story, it means you don’t yet understand the scope well enough, or the scope is too big to estimate easily. You don’t need exact estimates, but when you can estimate a story it’s also more negotiable. Plus you’ll be able to differentiate between valuable low effort and not so valuable high effort stories.
-
Small. You want the effort to implement a user story to be small. At most a few weeks (by one person), though many teams use ‘a few days’ as their limit. Smaller stories are easier to estimate. Big stories are harder to estimate, and thus less negotiable.
-
Testable. If your customer, in collaboration with and helped by the implementing team, can’t tell you how to verify you’ve implemented what s/he wants, you haven’t created enough clarity about the story yet. Writing down the acceptance criteria, also known as specification by example in BDD, before implementing the story, makes a team more productive by avoiding rework as a result of misunderstandings.
Writing User Stories Is Not the Point
The point is the conversation between users, business professionals, developers, and testers. It’s that conversation, the back and forth between the different perspectives of each participant, that’ll bring you better, simpler, and more valuable solutions to users’ problems.
The user stories you write are the means to communicate them and to retain the focus on and the value for the user during development.
How to Write a User Story in 4 Simple Steps
-
1. Start at the End
Agile development is all about delivering valuable software that satisfies customers’ needs. So that’s where you begin: the end goal, or value, a user is looking for.
It can help to think of it in terms of the problem s/he is looking to solve.
-
2. Work Backward
With the user and the end goal clearly in mind, you work out the steps a user would need to take to achieve their goal.
Trying to figure out the first step forward to reach a goal is difficult. You simply have too many options to pick from and no way to choose one over the other.
The way out is to work backward from the goal.
Let’s say your goal is to enjoy a strawberry smoothie. So you start there: a finished strawberry smoothie, ready for you to enjoy.
What do you need for that? Well obviously a glass, a straw, a smoothie, and putting the things together.
- get a glass
- get a thick straw
- make the smoothie
- pour the smoothie into the glass
- stick the straw into the smoothie
You have a suitable glass, but lack thick straws, so
- You have a suitable glass, but lack thick straws, so
You’ve never made a smoothie, but you know you need a blender, so
- take out the blender
- follow a recipe
To follow a recipe, you need to
- find a recipe
- buy the ingredients specified in the recipe
-
3. Small Is Beautiful
Big steps are unwieldy beasts that hide assumptions and details. When you find yourself wanting to add details to a step to clarify it, it’s often wiser to split the step into smaller ones.
Take the make smoothie from the example in the previous section. Unless everyone knows exactly how to make the smoothie you have in mind, you’re better off dividing it up into smaller steps.
-
4. Pen and PaperCards
When you’re clear on the steps and the value they bring in solving the problem you started with, you’re ready to write out the user stories. One story for each step.
Writing stories on cards, one per card, makes stories more tangible. You can manipulate cards directly: move them around on a table or a board. And that is still the easiest way of prioritizing and scheduling.
User Story Examples
Here are some examples of user stories to make everything more concrete.
- As a product manager with a remote team, I want to put user stories on a digital board, so that we can all see the one we’re discussing in an online meeting.
- As a product manager with a remote team, I want to invite members of my team and up to 10 others to an online meeting, so that we can collaborate to detail user stories that will be implemented soon.
- As a product manager with a remote team, I want to create and edit a list with the members of my team, so that I add all of them to an invitation without having to add them individually.
How to Develop Software Starting From User Stories
User stories are high-level narratives lacking the details needed by developers and testers.
So, when a user story is coming up for implementation soon, you need to add the details that’ll keep everyone on track and prevent unnecessary (re)work.
Ron Jeffries came up with the 3Cs, 3 critical aspects, of working with and developing software starting with user stories
What Are the 3 C’s in User Stories
-
Card
You write your stories on cards and use these for prioritizing, estimating, and scheduling. You can add notes about priorities and costs, but you leave other details for the …
-
Conversation
You conduct conversations, open discussions, between the customer and those involved in implementing it to come up with specific requirements and provide the clarity needed for implementation.
Concrete examples are the best way to provide clarity. And executable examples give you …
-
Confirmation
You conduct conversations, open discussions, between the customer and those involved in implementing it to come up with specific requirements and provide the clarity needed for implementation.
Concrete examples are the best way to provide clarity. And executable examples give you …
User Story FAQ
Q: What’s the difference between user stories and features?
User stories describe the value a specific type of user gets out of an activity.
Features are about what the software can do. It’s quite possible, and unfortunately very common, to specify features that bring no value.
Q: What’s the difference between user stories and requirements?
User stories describe the value a specific type of user gets out of an activity.
Requirements are about what the software has to do and how it does that. Generally, requirements state the criteria that features of the software need to satisfy.
You generally add requirements to a user story in the form of acceptance criteria by collaborating with your customer. In other words: a user story has requirements in the form of acceptance criteria.
Q: Who creates user stories in Agile?
In Agile, creating and writing user stories is a collaborative effort. You get the most benefits from user stories when they’re created in open discussions between customers, business professionals, developers, testers, designers, and other people with a stake in the software.
Become a Storyteller and Wow Your Customers
As you now know, user stories are a great way to keep everyone focused on delivering value for your users. Uh, customers. Uh, both.
And conducting collaborative conversations around the user stories will ensure that you create solutions that are better, simpler, and more valuable. Solutions that are exactly what your users need. No more guessing and pumping out features that sounded good, but nobody’s interested in.
So, go out and become a storyteller.
Signup for updates!
Check out Nimble Now!
Humanize Work. And be Nimble!
