How to write great backlog items
What makes good backlog items?
Is this a good user story or a feature?
It’s a good question, especially because quite often the way your story or feature is written determines a lot in how it gets implemented and whether it will be beneficial to the customer and to the business.
Let’s take a closer look into what makes good backlog items.
First and foremost, they need to represent value. This might seem trivial or almost obvious, but you don’t want to underestimate the importance of this. Too many organizations and teams operate with backlog items which they call stories and features that nevertheless carry no value to the user or to the business but are just bigger tasks. As a result, timebox ends and quite a bit of work has been done, but no value has actually been achieved. A good way to write user stories is by focusing on who is it FOR, what it enables them to do, and what’s the benefit of that, basically connecting the work to the customer outcome. Similarly, a good feature usually contains the outcome statement or business benefit description. Sometimes you are unable to write a backlog item in a way that represents value because that backlog item is a result of splitting of a larger item roughly speaking into big tasks. Setting up a database for the whole application is a large task, but it carries no direct value. The work must be split differently, so that each valuable slice contains database work, UI work and so forth. And your items should better fit in those timeboxes. At some point, your stories, for instance, must fit into your sprints, otherwise you will not be creating an increment of value every sprint.
Knowing when done
Next, you need to clearly know when the item is completed. This implies that some sort of acceptance criteria is needed. And it’s good to keep that acceptance criteria quite specific. One good way to create solid acceptance criteria is as follows. The team, during the planning, or maybe during the backlog refinement session that may precede planning, picks a backlog item. After a brief introduction, the team is performing a simple exercise: close your eyes and imagine that you are at the end of the timebox and this story is finished and is being demonstrated. Describe what you see. And then just capture the result of this exercise as your acceptance criteria.
Navigating the unknowns
Lastly, in complex effort there’s always a lot of unknowns. When we create a backlog item, add description, acceptance criteria, etc., we are making assumptions; or, in other words, basically, placing bets. We bet that this functionality will be beneficial to the customer, or that it will have proper scalability, security and so on. Some of those bets will work but some of them won’t. And you need to know which ones aren’t going to work and the sooner you know this, the better. Because then you can come back to your backlog item and update it, so it would better reflect reality. So, fast, deep feedback loops are absolutely crucial, and a truly good backlog item is the one that is open to modification or correction as the new facts present themselves. Remember that it is too easy to write a perfect user story or feature that will have nothing to do with reality.
Pick one or two simple improvements of the way your stories or features are handled today and apply them, don’t wait. Sustain that new approach for a while, you’ll start seeing the results.