What is the Meaning of Backlog and User Stories
What is a backlog?
In the recent 6-7 years (at least where I come from) user stories have become the norm. They are in the backlog, people create increments based on them, they even serve as documentation in some places. Some people have even transitioned from use cases and functional specs to user stories.
In this blog post, I’ll try to fix some of the resulting injuries and answer a simple question: “What is the meaning of backlog?” So let’s go.
The answer is simple – Product Backlog Items, but given the abstract nature of PBIs there’s a varying degree of comfort that this answer provides. And it depends on how much you already know about Scrum.
So let’s presume you’re only starting with Scrum, and dive in.
A good PBI should give you a clear idea of what needs to be built. The PBI is a part of the increment – what gets shipped at the end of the sprint. It can be a standalone unit within the increment, meaning it provides customer value on its own, but it’s not mandatory. It can provide value when shipped together with other PBIs that make up that sprints increment. E.g. it can be a whole feature, but it can also be a part of a feature that will make it into an increment.
When talking about parts, all parts of a feature should fit inside a sprint. If the feature is too big, decompose it into smaller features. There’s no shortage of decomposition techniques, so explore, learn and employ one that’s best suited for your context and feature at hand. Otherwise, you’ve finished PBIs that provide zero customer value, and you’ve entered the overflow land where PBI and Goal management is much harder than it needs to be.
In conclusion, the main focus of a PBI is towards what needs to be built. Not on why and definitely not on how. However, this gives little or no information about how PBIs tie in with requirements, user stories, and specifications. So let’s use an example to sketch things out.
Stories are describing the problem that needs to be solved
See the differences? Could be many solutions to that problem, but in this case, the PO decides that a Christmas party is the solution. He or she then sources requirements from potential customers and the market – company employees, management, and potentially other companies – and gives them over to the development team.
The requirements are the starting point when creating the PBI, i.e. they represent the needs without being bothered by the implementation details. E.g. the requirement won’t say “place a form for creating a quarterly report at the top part of the Reports screen” but simply “users must be able to create quarterly reports”.
You might say it’s a subtle difference but it’s a very important one. One is vague and describes a goal, the other is very concrete and sketches the path to that goal. A developer can take a PBI and start building the increment, but can’t do so with a requirement. A refinement is absolutely necessary to decide which route to take and provide the necessary details.
Therefore, the requirements can’t be in the backlog. Which even the name suggests – it’s not called a Requirements Backlog.
The Product Backlog
Moving on, how does the specification tie into the Product Backlog? Do we keep the specs in the Backlog? The answer is “no”. The specs live as a separate set of artifacts. Usually, you don’t start a sprint with a complete spec, rather with an Enabling Specification that should facilitate a healthy exchange between programmers, analysts, and testers, and a couple of decisions on what to build. All with the aim to flesh out the last bit of details needed for programming and testing, which feed back into the specification and enable finishing it up.
Okay, so where do user stories belong? Short, and by now hopefully an obvious answer – not in the backlog. Long answer – read on.
First, a deconstruction of the term – User story
The user is a human being that’s using your product. User is a certain individual, someone with a social security number, a living and breathing homo sapiens. This individual is not a persona, not an average user, and not a minimum common extract of any kind. The word “user” is quite self-explanatory, really. It’s singular, so it can’t be any kind of average, and he or she is using the system.
Okay, let’s see what’s behind the next word – a story. What first comes to your mind when you hear the word “story”? I don’t know about you, but I get at least a bit excited – there must be surprises… Intro, build up, peak, gradual roll-off, the finishing point, and the end. You know, Hansel and Gretel, Pinocchio, Three piglets – that’s the stories I’m talking about.
So let’s combine. A user story is a story that a user tells. The medium is usually – voice. Sometimes email, feedback form, or a Tweet. There’s usually quite a lot in these stories, they’re usually vague, sometimes contradicting, and quite often unique. But they’re the best material to start sourcing story maps, journeys, and requirements from, all of which will go into an analyst’s head. The result will be a specification which the developers can work from.
So, where do user stories belong?
User stories, vague as they are – don’t belong in the backlog. They belong to the story map (by Jeff Patton), focus group interview materials or similar places. I’m sure you can figure it out.
Lastly, there are people that have data models specified in their stories. Along with scenarios, steps, outcomes, acceptance criteria and even tests. If that’s you, my dear reader, then sorry – you don’t have user stories, cause I don’t know a single user who could have produced that. That’s probably the work of some analyst working his but off, maybe even with a developer and a QA playing three hats. And none of those three are users telling their stories. Never were, never will be. They’re all too biased to be called “users”.
Is that a PBI?
If it contributes to an increment that brings value to the client at the end of a sprint – then yes it is. But it’s a really good idea to have specs in Use Case or some other format that details how the system works and what it does.
And it really is a good idea. Because if all you do is keep the specs in Jira tickets, no one knows what the system should do. Face it – you have to dig through Jira history and construct a spec from a bunch of PBIs to know what the system should do. And heaven knows if you found all the relevant ones. Especially if you’re in sprint number 93.
I hope that I’ve shed at least some light on what’s in the product backlog and what’s not. It’s very common to missunderstand the PBI and Product Backlog, when playing the Scrum game, but thankfully we have the Scrum Patterns team that’s clearing things out quite well.
