Better backlogs, part 1: Introduction
I work in a sizeable software company — one that’s sizeable after a fast growth sprint. Our headcount has gone from 0 to 180 in under four years. Product development practices need to scale in parallel, and we’re making a big push towards adopting agile practices.
Now, I’ve worked with agile customer projects and internal agile teams for a large portion of my work history, and I share my experiences and perspective as a designer quite often to the people and teams I work with. I don’t work as a product manager or a PO, but still the biggest and most frequent question that I find myself finding answers for is:
What are good user stories like in a product backlog?
Let’s start looking for answers.
Problems and solutions
A product backlog should quickly communicate the direction of a product and its upcoming features. Well, not just the features, but the benefit its end-users will get from it with every release. User stories are a way of documenting this information in a standardised, if a little bit vague format that most people working in the software industry today are familiar with.
Product backlog is a prioritised list of these stories. A user story should describe user needs, business needs and the general problem space so that every developer can use this insight when making small decisions in their implementation.
Solving a big problem is often done by breaking it down to multiple smaller ones. In the same way, a product backlog typically starts with a small number of very high-level stories that are then broken down into smaller ones with gradually increasing level of detail. These are easier for humans to understand, research and find potential solutions for. It’s also easier to validate if and measure how well you have solved a small problem once you think you have the perfect solution.
Properly written user stories document product decisions and the motivation behind them so that any team member, contributor or stakeholder has a shared reference. A product backlog is also a easy to come back to in the future to understand what has been done, and stories help writing release notes and preparing user tests even after they’re done.
Delivering solutions
The high-level recipe for agile product development workflow, from my perspective, is quite simple:
- User stories are problems.
- A development team delivers solutions.
You can think of a well-functioning agile development team as a machine that runs on caffeine and turns a user story into a new release. The machine did all the changes and additions that it thought was necessary to solve the problem that the user story described.
But Jerry, how do I make sure that my developers don’t do something stupid?
Well, usually developers are smart people with good analytical problem solving skills. By giving them a view to an entire backlog you give them an idea of upcoming features and the direction of the product. They can prepare and avoid conflicts when making design and tech choices for the features they’re delivering right now.
Even when user stories are high-level, vague and in desperate need of splitting, having a shared understanding of the end-user perspective and motivations behind the work that goes into your product helps everyone deliver better results, and helps a development team give input, take responsibility of the product, not just do what they’re told and then get stuck when every single detail wasn’t specified in perfect detail (which never happens).
Stories as input for design
You might be used to designers working in their own floor of your company with their own separate workflow and task management, as an external force acting upon the development teams that work in agile sprints. I think this is a bad practice, mainly because in this arrangement a designer does not take responsibility for end-user output and is not exposed to the realities of software development that will affect the end-user experience. Wireframes, mockups and prototypes are only internal design documentation, not something the end users ever see or even care about.
So what does a designer actually do in an agile team?
Well, on a high-level, every product or UX designer should regard themselves as a problem solver: we’re doing what we do to deliver creative and elegant solutions for the problems that our users face.
What do we need to get the job done? Descriptions and definitions of the problem. Data and data analysis. Information on the users we’re targeting and the impact of our solution should deliver. A good user story includes all these things.
Ideally a designer or a developer — really anyone in the development team regardless of their role — should be able to pick up a story independently. The team should reject user stories that do not contain adequate information on the problem space in a written format.
Checklists
You’ve probably seen this list before, but here we go.
A good user story should…
- follow the format “As a <type of user>, I want <some goal> so that <some reason and benefit>.”
- include a clear description of the benefit for the respective user group
- have some form of acceptance criteria
- document the rationale that motivates tasks (if we wrote only tasks, we miss documenting that rationale)
- if possible, reference the metrics that we aim to improve (even if it’s “developer time”, “user delight” etc. — something other than your KPI)
This format aims to guide and improve the quality of…
- design decisions
- preparing design output and design specs for development
- technology choices and architectural decisions
- communicating a feature’s value to stakeholders
- conducting user tests
- preparing analytics and A/B tests
- preparing feature toggles
- measuring impact
A story can include suggestions or examples of possible solution(s), but should not be fixated on a specific one. I’d advice to resist the temptation to add even that without clear background information on why a particular solution might be desirable. Stick to the problem space!
Summary
I keep coming back to these notes when evaluating our stories and discussing our product-design-development workflow. I think I’ll come back to the specifics in future posts.
A few things to keep in mind:
- User stories aren’t in the ten commandments: there are other ways of documenting user needs and other ways or formatting a backlog, like job stories. The general mindset I’ve talked about still applies though.
- The user story template is very generic and easy to abuse. You need to understand the thought process behind it, not just shoehorn a todo list to match the template. Same goes for many other templates.
- Learning to write good user stories, if you’ve never done it, takes time. Keep writing, get feedback. There are mountains of literature and materials online on user stories to help you on your way.
- Spending time on user stories might feel dumb or needlessly complicated, but I can guarantee you that there’s a massive return of investment waiting for any team that masters this particular craft. I’d wager that most people who have worked with good user stories will tell you the same.
Quality in user stories will transfer into quality in end-user experience. I’m not the biggest fan of user stories personally, but this is not in contrast to having no set format or criteria for problem definitions and product documentation. I’m sure there’s something better out there, but they’re still a pretty good, tried-and-true way of going about it.
That said, I am working on that something better.
Thanks for the read
You can read more about my work as a product designer and developer on my site at jerryjappinen.com or follow me on Twitter. Thanks for reading!
