Product versus Sprint backlog
I was reading a long and strange rant against Agile recently. It’s this one, if you’re curious and you have a lot of time to burn. It confirmed my belief that people often don’t understand the difference between the Product Backlog and the Sprint Backlog. This is a really important distinction. If people get it wrong, you can find yourself in the horrible mutant forms of Agile / “Scrum-but” that are described in that rant.
The official Scrum canon says there are only three roles: Developer (person who builds stuff in some way), Scrum Master (person who helps the Developers build stuff and coaches the team on Scrum), and Product Owner (person who defines and prioritises the work to build the product).
Some people think that the Product Owner is therefore the “boss” or “manager” who decides everything and tells people what to do. And the Scrum Master is his sinister right-hand man, enforcing his orders. And the dev team are hapless minions pushed around according to the whims of the Product Owner and/or Scrum Master.
That view is completely wrong. The Development team actually have all the power. The key to this is understanding what exactly they get to do. And understanding the difference between the Product versus Sprint Backlog in Scrum is.
A quick summary of the key difference between the Product Backlog and Sprint Backlog is:
- the Product Backlog is the big “master list” of all possible work on the product
- the Sprint Backlog is plan of work for the current sprint
- the Product Owner manages the Product Backlog, the developers manage the Sprint Backlog
- the Product Backlog can have things come into it and move out of it all the time, since none of it is being worked on
- the Sprint Backlog is more fixed, and doesn’t usually have things added to it or removed from it (except when backlog items are complete).
Now let’s explain this in more detail.
Product Owner and Product Backlog
The Product Owner gets to do one thing in Scrum, really: manage the Product Backlog. They get to put things into the Product Backlog, take things out of the Product Backlog, and change the order of things in the Product Backlog. That means they effectively have control over product scope / project scope. They decide what gets built.
Well, not qute. They get to decide what might get built. The Product Backlog is a list of things (features, stories, “Product Backlog Items”, fine). These are things that the Product Owner wants someone to build at some point. But nothing in the Product Backlog gets worked on. It just sits there, waiting for someone to put it in a sprint.
Developers and the Sprint Backlog
The developers actually get to decide what work gets done, because they decide what work goes into a Scrum sprint. That is, what work gets moved from the Product Backlog into the Sprint Backlog. Which is a list of work that will be done this sprint. The Scrum Guide is explicitly clear on this: the Scrum developers Scrum (not the Product Owner) chooses what work goes into the sprint backlog.
They also choose the order in which it is done. And how it is done. And who does what work.
Tasks are assigned on a pull system, i.e. they don’t go anywhere until someone to chooses to pick them up. And they decide on the implementation, i.e. how stories are built. The Product Owner decides none of these. If the scrum team want to pick up no stories and do no work each sprint, they can. They are perfectly within their rights according to the scrum guide to do that. They are actually wielding all the power.
How does work move into the Sprint Backlog?
At the beginning of every sprint, the developers (not the product owner, not the scrum master, the developers) choose what work to move from the Product Backlog into the Sprint Backlog. This happens in an important meeting called Sprint Planning (I wrote more about Sprint Planning here).
Those backlog items now become the scope of work for the sprint just starting. The team also comes up with a sprint goal, which should roughly correspond to the scope of work they have moved into the sprint i.e. the sprint backlog.
But what if the work isn’t ready for the sprint backlog?
Sometimes work is not ready to move it into a sprint. Usually, because the team don’t feel they have sufficiently defined and analysed it. It might need some more “backlog refinement” (please don’t call it backlog grooming, whatever you do).
Work isn’t always ready to be included in the sprint backlog.
That’s fine. The development team get to decide that. The Scrum guide recommends (I do too) that the scrum team do regular Backlog Refinement activities. This should mean that there are always some items that are understood by the team well enough to be moved into the sprint in the next Sprint Planning meeting. If you are doing two-week sprints, then an idea might be to have a two-hour meeting in the middle of the sprint to do this.
What about the scrum master?
The scrum master has even less power than the Product Owner. They don’t get to put anything on or take anything off either backlog. And they don’t get to choose work, priorities or implementations. They help facilitate rituals, ensure the team has the tools to get their job done, and coaches the team and organisation on Scrum. That’s it.
It’s a servant-leadership role. Anyone who sees it as a license to boss people around does not understand Scrum.
How is the Product Backlog built and developed though?
The Product Backlog is owned by the Product Owner. They are accountable for it and they control it. The Scrum Guide does say that the actual work of creating and managing backlog items doesn’t necessarily need to be done by them.
Product Backlog Refinement is best done as a group, collaboratively
It says they can delegate this work to others. So you might have a Product Owner in a team, and one or more business analysts as well. And the Product Owner focuses on the Product Goal, Product Roadmap and so on. While the business analysts do the actual creating and refining of the backlog items.
I like to get everyone on the team involved in Backlog Refinement. Rather than have a Product Owner or business analysts “throw stories over the wall” to developers, get them all in a room together. Write the user stories and other backlog items together.
This kind of discussion / conversations / collaboration are at the heart of successful agile and Scrum. We don’t want to go back to the bad old days of people emailing documents around to each other. Get in a room and talk to each other!
Don’t forget the “three Cs” of user story writing: Card, Conversation, Confirmation. The Conversation part is the most important!
This video does a pretty good job of explaining the difference between Product and Sprint Backlog.
Frequently Asked Questions
Is Product Owner the same as Sprint Backlog?
No, Product Owner is a role (actually an accountability) on the Scrum team. The Sprint Backlog is one of the three Scrum Artifacts (along with Product Backlog and Increment). It is a plan of work for the current sprint. The Product Owner doesn’t really touch or control the Sprint Backlog.
What is the major difference between Product Backlog and Sprint Backlog?
The major difference is the scope of the artifacts. The scope of the Product Backlog is the current entire set of ideas for the Product. Over all its time. The Sprint Backlog is scoped to just this current sprint. Work that isn’t going to be done this current sprint shouldn’t go into the Sprint Backlog.
What is the Sprint Backlog in agile?
The Sprint Backlog is an artifact in Scrum, which is one of the many frameworks for agile software development. The Sprint Backlog is a plan of work for the current sprint. It includes the why (the sprint goal), the what (the backlog items chosen for the sprint), and the how (a plan for how to deliver the items and achieve the goal).
What is a Product Backlog with an example?
A Product Backlog is an ordered and emergent list of all the possible ideas for improving the product. It includes the Product Goal (the reason or objective of the product), and all the Product Backlog Items that can be worked on. These will (hopefully) raise the value of the product and get you closer to the Product Goal.
