23/36 : 📚 A Guide to Effective User Stories and Story Mapping and Pointing
23/36 : 📚 A Guide to Effective User Stories and Story Mapping and Pointing
User stories: the compass that guides agile development towards user-centric solutions
👋 Hey PMs
We’re thrilled to announce our Product Discovery Course!
🎓 "From Pre-Discovery to Solution Execution" is a comprehensive course on product management techniques and strategies.
"The BEST INVESTMENT you can make is in YOURSELF " - Warren Buffet
What are user stories?
A user story is an informal, general explanation of a software feature written from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.
User stories:
Are easy for anyone to understand
Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
Help the team focus on real people, rather than abstract features
Build momentum by giving development teams a feeling of progress
The 3 C’s (Card, Conversation, Confirmation) of User Stories
Card – a written description of the story used for planning and estimation.
Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build a shared understanding.
Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.
Types of User Stories
We can classify user stories into functional and technical types:
Functional – Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user. Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story.
Technical – Technical stories are written to be able to support the functional stories. Technical stories can be classified as
Infrastructure stories – any infrastructure addition/modification that may be required to support the functional story
Refactoring – this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well
Spikes – stories that require research on architecture and design which may in turn help achieve the functional need of the customer.
Why create user stories?
For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.
User stories serve a number of key benefits:
Stories keep the focus on the user. A To-Do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.
How to write user stories
Consider the following when writing user stories:
Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For Whom? If there are multiple end-users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
How to Write Good User Story with INVEST Guidelines
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story.
Independent – Each User Story should represent a distinct and independent set of business values such that, were it released on its own, it would deliver incremental value over the previous state.
Negotiable – While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.
Valuable – The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.
Estimable – We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)
Small – User Stories should be small enough that they are able to be completed within a sprint.
Testable – All members of the team need a clear and precise way to verify whether or not a User Story has been completed.
User Story Example :
UseCase: when we build a website that has two types of users ‒ logged-in users and guests ‒ we’re likely to write the following acceptance criteria for a user story that defines the sign-in feature for a logged-out user:
As a logged-out user
I want to be able to sign in to a website
So that I can find access my personal profile
Scenario: System user signs in with valid credentials
“Given I’m a logged-out system user
and I’m on the Sign-In page
When I fill in the “Username” and “Password” fields with my authentication credentials
and I click the Sign-In button
Then the system signs me in”
The Given/When/Then template helps you reduce the time spent on writing test cases since you describe the system’s behavior upfront. We prefer writing acceptance criteria with the first-person “I” since it helps us talk from a user’s perspective and keep a user’s needs in mind.
User Story Splitting
The goal of story writing is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days.
Before a user story is ready to be scheduled for implementation in an upcoming iteration, it should be “small enough,” the usual rule of thumb being “a story that can be completed within the iteration”.
However, many user stories start out larger than that.
“Splitting” consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.)
There’s usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution. These “splits” are intended to help you do that.
Why Story Splitting Matters
Working from a prioritized backlog of small user stories allows a team to get value and high-quality feedback on frequent intervals.
Many teams struggle to split large user stories and features into good, small stories.
Instead of ending up with small vertical slices through their architecture, they get stories that look more like tasks or architectural components and fail to experience the value or feedback small stories should provide.
Fortunately, story splitting is a skill that can be learned in a relatively short time. We’ve seen teams go from struggling to fluently splitting stories with just a couple hours of practice and some simple tools.
What Makes a Good User Story?
Before we can talk about splitting user stories, we need to make sure we have a shared understanding of what a good story is and what sorts of things can and can’t be split into good stories.
A user story is simply a description of a change in system behavior from the perspective of a user. It describes something a user wants to do with the system or wants the system to do for them that it doesn’t do today.
User stories are great for translating that customer empathy into a series of changes to a software system while maintaining the user’s perspective throughout.
The goal of story writing is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days.
This allows the product owner and the team to get quick feedback on the larger feature being built, with the expectation that this will steer the ultimate direction of the feature and maximize user value.
Story-splitting techniques
There are many techniques for splitting stories. Here are some of the more useful ones.
Split by capabilities offered This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each one into its own story. For example, the capabilities “sort and search” may each be its own story. Splitting further, each way of sorting or searching may be its own story.
Split by user roles Administrators interacts with a system differently from normal users. Teachers interact with instructional software differently from students. By defining the different roles in your system, you can split features and stories to address the unique needs of each role.
Split by user personas Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.
Split by target device You can’t assume that users are interacting with your system using a standard computer. Various smartphones and IoT devices need to be considered in your stories. Splitting stories by device provides a more natural experience for your users.
Cynefin and Story Splitting
Dave Snowden’s Cynefin model is a helpful way to think about the right strategy for a problem depending on its complexity. We find Cynefin so useful, we include it in almost all our workshops, either as prerequisite content or in the workshop itself. If you’re not yet familiar with the model, check out our overview.
Story splitting looks different for each Cynefin domain. Here’s how:
Obvious – Just build it. Or, if it’s too big, find all the stories, and do the most valuable ones first.
Complicated – Find all the stories, and do the most valuable and/or most risky ones first.
Complex – Don’t try to find all the stories. Find one or two that will provide some value and teach you something about the problem and solution, build those and use what you learn to find the rest.
Chaotic – Put out the fire; splitting stories probably isn’t important right now.
Disordered – Figure out which domain you’re in before splitting so you don’t take the wrong approach.
The most important nuance is in the complex domain, where starting the work will teach you about the work. In this situation, it doesn’t make sense to try to find all the small stories that add up to the original, big one. Instead, it’s more productive to find one or two you can start right away in order to learn.
Some are uncomfortable with this approach, wanting all the stories enumerated and sized to be able to project time over the backlog. But if you’re really in the complex domain, this only gives you the illusion of predictability—the actual stories are likely to change as you get into the work. Better to be transparent about the uncertainty inherent in complex work.
Vertical vs Horizontal Slices
You’ll often hear the term vertical slice in reference to good stories. This is about the shape of good stories relative to software architecture.
A vertical slice is a shorthand for “a work item that delivers a valuable change in system behavior such that you’ll probably have to touch multiple architectural layers to implement the change.” When you call the slice “done,” the system is observably more valuable to a user.
This is in contrast with a horizontal slice, which refers to a work item representing changes to one component or architectural layer that will need to be combined with changes to other components or layers to have observable value to users.
Let’s look at a really simple architecture. There’s a UI layer, some business logic, and a database. Your system may be more complicated than this, but it probably contains at least these three layers.
To get most of the INVEST attributes, a story is necessarily going to touch all 3 architectural layers. We probably won’t be able to deliver value without some UI changes, some logic changes, and some persistence changes. Thus, a story is a vertical slice through the system.
What is user story mapping?
User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. It is used to improve teams’ understanding of their customers and to prioritize work. Software leader Jeff Patton is often credited with having developed and shared extensive knowledge around user story mapping.
In user story mapping, teams create a dynamic outline of a representative user’s interactions with the product, evaluate which steps have the most benefit for the user, and prioritize what should be built next. For agile organizations, it provides an alternative to building a flat list of backlog items or working from lengthy requirements documents.
User story mapping employs the concept of user stories — which communicate requirements from the perspective of user value — to validate and build a shared understanding of the steps to create product users love. Teams write user stories in a format that captures business value and can be completed within a development iteration (usually called a sprint).
By visually mapping out these user stories, product teams tell the story of the customer journey and break it into parts. This helps them design and build the functionality that is focused on desired customer outcomes, instead of solely on development output or feature specifications.
Why User Story Mapping?
Story Maps were first introduced by Jeff Patton in 2005. The main idea behind Story Maps is that single-list product backlogs are a terrible way to organize and prioritize the work that needs to be done. A richer structure is necessary. A user story map is a powerful tool that enables an agile team to groom their product backlog and plan the product releases more effectively.
A user story map captures the journey a customer takes with the product including activities and tasks they perform with the system. Creating a story map collaboratively ensures team members are on the same page from the start of the project through to ongoing development of new releases.
Here are few benefits of using story map as a user story tool:
Manage backlog with an overview and leveled structure
Brainstorm, discuss, and prioritize user needs in a collaborative approach
Manage activities and tasks (walking skeleton), and divide them into epics or user stories systematically
Arrangement and prioritization of user activities and user tasks, or drill down to refine them into related epics or user stories
Manage user stories online for both remote and co-location environments collaboratively for keeping everyone in your team on the same page.
Benefits of user story mapping
The approach described by Jeff Patton is just one of many ways to structure the story map. In any case, the manner in which we organize backlog items inside the map offers the following benefits:
Clear priorities. The general approach of how a story map is structured makes it easy to prioritize each story, preserving the connection between big and small items. “Prioritization becomes easier as a story map begins with the backbone that is not prioritized. You need all of those things since they are required to create an MVP to start off with something. By using the backbone, it’s easier to see where stories or tech tasks belong and where the gaps in functionality are,” explains Vlad Khilchenko, a product manager at AltexSoft.
Built-in user journey. The backbone of a story map is an oversimplified version of a user journey map. While they are structured differently and are used for different purposes, the product team will be able to navigate the backbone’s steps. Additionally, each step can be widely expanded by stories, providing more context to each piece of functionality.
Visible product goals and vision. A story map is a dynamic document that will expand as the product grows. Having a bird’s-eye view of the project, and understanding where it starts and where it ends, the team can grasp the vision of the product and how to implement it on a technical level.
Helps to avoid backlog grooming. Large-scale projects may last years. As the product moves closer to its release, items in the backlog may lose their relevance, and thus should be reviewed. The act of backlog “cleaning” is called a grooming or refinement session. If you structure your backlog as a story map, items are always placed according to their priorities.
Better communication. Product backlogs are created by a single person, a product owner. Contrary to that, story maps are done during the mapping workshop that involves many team members. This facilitates discussion about the product right from the beginning.
As we can see, the practice of story mapping is a much more flexible and transparent approach to communicate product ideas. As any document in agile, it’s done with the purpose of building working software. That way, a map can be built in any way you want, given that you stick to the main idea.
What is a Story Point?
Story points represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories.
When the product manager wants some features to be developed he/she desires to know how soon the team can complete the features and how many resources it will take to complete the work. From the developer’s perspective, it’s next to impossible to predict the exact time in which he/she can complete the work. The person can, however, give a rough estimate in terms of how much time it might take to complete the work. Note that instead of “will” the developer chose to use “might” because he/she is not absolutely “sure” about the time factor but “feels” it might take that much time. This is user story estimation in a nutshell.
You don’t give an exact number explaining how complex the story is and how long it’ll take to develop – you give a rough “estimate”.
We are good at comparing size, so estimating a story using a Fibonacci series sequence (0, 1, 2, 3, 5, 8, 13, and 21, etc) gives more clarity of its complexity and relative sizing in terms of development. It is helpful to have a set of stories nearby to make a comparison and recommendation to set priority.
While estimating stories, Consider :
Complexity: Consider the complexity of the story.
Risk: Consider the team’s inexperience with developing this story.
Implementation: Consider the implementation factors.
Deployment: Consider the deployment requirements.
Interdependencies: Consider other outside issues.
Advantages of using story points for estimating work
Story points are a measure of relative size and complexity.
Story points are unitless, meaning as a scale, they are only valuable to compare against each other within the same team.
Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).
Estimating story points is fast and easy.
Story points initiate high-level discussions about everything that is involved in a project.
Earned points can be used to generate the teams’ velocity which can be used to predict future work capacity.
Story point estimation Cheatsheet
