Mastering User Stories – Part 2 | Crafting Clear User Stories: Slicing, Structure, and Succinct Titles
A guide for Product People to learn actionable techniques to write user stories that are quicker to implement, and deliver value
Welcome back to the “Mastering User Stories” series! In Part 1, we unpacked the true purpose of user stories, emphasising their role in sparking conversation and fostering shared understanding. Building on that foundation, this article dives into the practical “how-to” of crafting clearer, well-structured user stories.
In this instalment we discover how to write user stories that actually help your team create value quicker. Below, you’ll learn effective techniques for
slicing stories into manageable pieces,
ensuring an end-to-end focus, and
giving them succinct, descriptive titles.
They are informed by frequent challenges I’ve seen with user stories.
How to break user stories down
Slice stories into small pieces
Oversized stories reduce team morale and productivity. Stories are often too large, leading to developers working on a single story for a week or two. This can easily make them feel demotivated and like they’re not making progress.
Large stories hide misunderstandings until it’s too late. In these cases, we also realise too late that we didn’t have common understanding, and developers implemented something different than the product manager or designer imagined we had agreed on.
Because of these reasons, I advocate for slicing stories into small pieces.
How to plan your user story slicing effectively
Prepare user stories before planning sessions. As a product manager, it’s a good idea to prepare the user stories before your planning or refinement session. So, you have time to think through the user flow based on the designs (if your product has a UI) and consider how to slice the stories effectively.
Aim for small, testable pieces of functionality. When you’re thinking about the scope of a user story, aim for a small, end-to-end piece of functionality that your team can easily test. You have to think through what actions your user will be doing in your product step by step.
User story example: Finding courses on a learning platform
Imagine you’re building an education platform (like Pluralsight, Udemy or Coursera) and you want to enable your users to find the right course for them.
What are the activities your user will do in your product to achieve this?
View the available courses;
Filter the available courses based on certain criteria;
Search for a specific course;
View the details of a specific course;
Sign up for their desired course.
If we put all of this into a single user story, your developers could easily get overwhelmed. It would also take them a long time to implement, so we wouldn’t be able to check quickly that this functionality was working as we expected.
❌ Don’t do this
Avoid combining multiple user activities in one story, it will make the scope too large. For instance:
As a learner, I want to view the available courses and view the details of a course I select, so that I can decide what to sign up for.
Watch out for the word “and” in your stories. If your story includes the word “and”, it’s likely that it’s trying to cover too much. The longer your developers work on something, the later you’ll be able to confirm whether it’s working as expected. If it doesn’t work that way, then it takes longer to correct, as more code was written.
✅ Do this
Focus on one step per story:
As a learner, I want to view the available courses, so that I can find what I want to sign up for.
This is simply about your user viewing the list of courses. They’re not searching, not filtering, and not clicking to see details – just viewing the initial list. That’s already a significant amount of work:
Your team needs to do a call to the backend to query all the courses.
To display the courses on the UI, you need to implement the right structure of information on the cards (content type, title, instructor, library, level, length, publication date).
You’ll need to add the necessary icons and hover behaviour.
For this user action to work, you also need to implement pagination that appears at the bottom of the page – or whatever loading you decide to apply in this case. On Pluralsight, they made the decision to display 18 items on one page and implement pagination. This should be its own story as its implementation is quite complex.
Use acceptance criteria to clarify the details. So, as you see, this user interaction is a lot of work, even though it seems like a small step for your user. Acceptance criteria can really help in clarifying all these details. Just ask yourselves, “What would we need to check to confirm this story is done?” For the structure of the acceptance criteria you can either use bullet points or Gherkin that helps your developers write test cases. If you and your team decide to use Gherkin, then each acceptance criteria will be its own scenario:
Scenario: The learner views the available courses
Given I am logged into the application
When I navigate to the courses page,
Then I can see the list of available courses.Scenario: The learner looks at a specific course tile
Given I am on the list of courses
When I look at a specific course tile,
Then I can see the content type, title, instructor, library, level, length, publication date of the course.Scenario: The learner hovers over the info icon on the course tile
Given I am looking at a specific course tile
When I hover over the info icon,
Then I can see the following text in a tooltip: “This course is only available in the libraries listed. To access this course you will need to purchase a package that includes at least one of these libraries.”
(I didn’t include error scenarios in this story on purpose, because my suggestion is to focus on the “happy case” first, then tackle error cases in separate stories. We are going to cover those in the next article.)
Collaborate with developers on story size. When you’re discussing user stories with your developers, don’t hesitate to ask, “Would it be helpful to break this down further?” Since they are the experts in technology, they will know what makes sense to implement together.
Remember the goal: rapid verification. The main goal here is to quickly see if you’re on the right track, either by releasing a small piece of functionality to production where your users can provide feedback, or by enabling the product team to test if a specific functionality (or sub-part) is working as expected.
How to write end-to-end user stories that deliver value
Why fragmented stories are problematic
I’ve seen many stories only focusing on either the back-end or the front-end of the application. If the story doesn’t cover a small slice of an end-to-end functionality (think of a slice of cake) that our user actually will do in our product, we cannot guarantee that the functionality will work well, from our user’s perspective.
❌ Don’t do this
Avoid creating separate front-end and back-end stories. When stories are split along technical lines (only a level of a beautiful layer cake) rather than user actions, we risk testing components in isolation without confirming they work seamlessly together. This approach can lead to integration issues discovered too late in the development cycle.
Don’t write stories that focus on the technical implementation:
Query the database for all the courses.
This doesn’t tell your team what value you’re delivering to users or how the feature will be used.
✅ Do this
Focus on the outcome your user wants to achieve. This results in an end-to-end user story. It might be something that in and of itself doesn’t create user value in the sense that you won’t release it on its own. If you think about our example of viewing the available courses, it’s not something we release to our users, until they can actually select a course – if our end-goal is to enable them to sign up for a course. But it’s still something we can test and confirm it’s working. It’s way easier to catch bugs in these small steps. When the full user flow is built out and we are testing everything at the same time, it becomes much harder to catch all the issues.
Write an end-to-end story even with specialised team members. You might have front-end and back-end engineers in your team, instead of ones with full-stack skill sets. I’ve been there. Even in this case, I’d recommend writing an end-to-end story and creating sub-tasks under it for the different parts. So everyone will have the complete picture of what we want to achieve. The team can keep this in mind when designing the API, communicating between the front-end and the back-end of the application. The product manager will only accept the story, once the full functionality is working and we can test it.
There is one caveat. It could happen that your user story doesn’t require your team to touch each part of the application (infrastructure, back-end, front-end). And that’s totally okay. Templates are here to help us, not hinder us. So, you can still think in the layer cake metaphor – it’s just a layer cake with holes (see the pic below). If you need to make a change in the infrastructure to make your application more efficient, you can still think in user stories. “What is the value our user/business/team gets from this change?”
Remember that the beneficiary isn’t always the end-user. It might not always be your end-user who realises the value of your implementation. It might be your business, for instance if you have to pay less for hosting your app on Amazon Web Services (AWS) after implementing an improvement. Then write that in your story!
As the Finance Manager, I want to optimise our cloud services so that our infrastructure costs decrease.
Naturally, the technical solution would come from your developers. You just need to know that the outcome the Finance Manager wants to achieve is decreasing the infrastructure costs. The “user” is typically the person who directly benefits from the feature being developed. In this case, the Finance Manager represents the part of the business who is concerned with costs. The user in a user story should be someone who interacts with the product or system, or someone who will gain value from the outcome of the feature.
How to write clear user story titles
Why story titles matter
The title of your user story will show up in your backlog and helps your team to identify the story. A clear, concise title makes it easier to track and reference stories.
❌ Don’t do this
Avoid using the full user story format as the title. Copying over the “As [a user persona], I want [to perform this action] so that [I can reach this outcome]” statement to the title will just make it unnecessary long and difficult to read.
✅ Do this
Use a short, outcome-focused description. Add a brief description of what the user will be able to do as a result of that feature.
The learner can view the available courses
This title clearly communicates the user outcome in a scannable format that works well in backlogs and issue trackers.
Putting it into practice
By mastering story slicing, ensuring end-to-end focus, and crafting succinct titles, you’ll significantly improve the clarity and testability of your user stories. These techniques are crucial for rapid verification and catching issues early. Take a moment to review one of your current large stories or a story focusing on a technical aspect, rather than a user outcome – how could you apply these principles to make it clearer and more actionable?
In Part 3 of our series, we’ll delve deeper into anticipating the unexpected, exploring how to identify edge cases and implement robust error handling, as well as focusing on outcomes to drive true product value.
Catch up with Part 1 of “Mastering User Stories”:
Mastering User Stories – Part 1 | User Stories Unpacked: The Power of Conversations
Welcome to the first instalment of the “Mastering User Stories” series! Over this four-part journey, we’ll dive deep into transforming your user stories from mere documentation into powerful tools for building better products and fostering shared understanding within your team. Before we dive into the “how-to” of writing and sharing, it’s essential to g…