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.
Product Owner and Product Backlog
The Product gets to do one thing and one thing only: 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 scope: they decide what gets built.
Well, no: 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.
Development Scrum and the Sprint Backlog
The scrum team (the “developers”) actually get to decide what work gets done, because they decide what goes into a sprint, i.e. 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 Development Scrum (not the Product Owner, they are not part of the scrum) chooses what work goes into the sprint backlog.
They also choose the order in which 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 development team (NOT the scrum team, 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. 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.
