User Stories: What They Are and Why and How to Use Them
- 8 mins read
-
By
Marjan Venema
- Updated on September 17, 2024
What Is a User Story?
A user story is a simple, concise description of a software feature from the perspective of the end-user or customer. It captures the “who,” “what,” and “why” of a requirement in an easy-to-understand format, typically following the structure:
☑ As a [user role],
☑ I want [goal/desire],
☑ S that [benefit/reason]
User stories are a fundamental part of Agile methodologies, such as Scrum and Extreme Programming (XP). They help development teams understand the user’s needs, prioritize work, and ensure that the software being built aligns with the customer’s expectations. User stories are typically written on index cards or sticky notes and serve as the primary input for the software development process, guiding the planning, estimation, and execution of work.
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.
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
- take out the blender
- follow a recipe
- 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
1. 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.
2. 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.
3. 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.
Having a reliable tool for managing user stories is essential for ensuring clear communication and efficient progress tracking. Nimble’s user story feature offers a streamlined solution, providing teams with the necessary tools to effectively capture, prioritize, and track user requirements throughout the development process, ultimately leading to successful project outcomes. Learn more here.
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
1. 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 …
2. 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 …
3. 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.
Share the Knowledge
About Author:
Marjan Venema
Simplifying Project Management!
Explore Nimble! Take a FREE 30 Day Trial
Agile 101
What is an Agile Epic? Benefits of Using Them
Learn what an Agile epic is, how it can streamline project management, and the benefits of incorporating epics into your Agile workflow.
Is Hybrid Agile Right for your Team? Here’s what you need to know
Explore the suitability of Hybrid Agile for your project needs in our comprehensive article. We delve into the benefits, considerations, and key factors to help you determine if this approach aligns with your organization’s goals and project requirements.
What is Hybrid Agile Project Management? A Short Guide
Discover the power of Hybrid Agile project management: achieve flexibility and structure for successful project execution. Learn how to harness this dynamic approach.
Dynamic System Development Method (DSDM)
Dynamic Systems Development Method, DSDM for short, seeks to do what came to be known as ‘Agile’ well before the manifesto was written. Learn more about its philosophy, principles, pillars, and practices.
What is Scrum Methodology? An Introduction for Agile Teams
Scrum is an agile project management framework that prioritizes collaboration and iterative development for efficient results.
Scrum of Scrums: A Starting Point to Scaling Agile
Scrum of scrums is an approach to coordinate multiple scrum teams working together. Learn how it works, how to get started and how it differs from competing approaches.
Pair programming is a programming method in which two people work together on a single program. The first person is the “Driver”, who writes the code, the other person is the “Navigator” who reviews each line of code as it is typed, checking for errors. They exchange their roles on a regular basis.
Code refactoring in Agile is a well-known technique to keep a codebase healthy and amenable to change. Learn what it is and a sound process to follow.
