Product Backlog vs Sprint Backlog

Working with my clients I’ve observed there’s a common misunderstanding on what the Product Backlog (capital letters) should contain.

I think several big statements have contributed to that confusion starting with that “the Product Backlog should contain everything that could possibly get done”.

What I’ve observed is that statement has been misunderstood as really “everything”.

So, the Product backlog ends up becoming a to-do list.

And it’s even worse when we misuse the “User Story” concept and express that to-do list using the (sadly now…) famous “as a… I want… so that…” chain.

Specially when the user (the real one) is far away from that phrase.

As a me/myself/I I want to do this thing so that I get that thing done.

Olé, voila, there you go, a great user story.

So I think we need to go back to what purpose the Product Backlog serves.

Why

The Product backlog is a communication tool.

It helps Product Management / Ownership to order what things they value more based on a myriad of factors we summarise as “value” which usually but not always links to return of investment.

To do that job, Product Owners need to trade on items on the same currency.

That helps the product development team to truly understand what “value” means in this context.

What it is we are trying to achieve.

What it is the outcome we expect by delivering the output we design, and develop.

I can trade croissants over bread.

I can trade selling croissants to that segment of the population vs another, because I’ve got the hypothesis they’ll bring more friends.

I can trade a so-so croissants over a perfect one, because I know time matters in this place.

I can trade ovens that enable me to cook more stuff over tomorrow’s croissants (here we have an “enabler”)

But definitely I cannot trade any of that over “go shopping”.

It’s just not the same currency.

I can’t order the backlog then.

“As a cook, I want to buy flour so that I can cook” is NOT a good “user story” in that context.

“As a cook, I want to buy sugar, so that I can cook croissants” is still not good enough.

The Product Backlog

Product backlog should be focused on “product hypothesis”.

And let me for a while ignore the template “as a… I want …so that…” and use a simpler, straight forward: “By doing this thing, I expect to get that value”.

To write that simple thing down, I should have gone through a conversation that helps me to align the consumer of the thing, the product management, and the team on what I value, and what hypothesis I’m making on how to achieve that value.

That will change for the good the dynamics of 3 key elements:

The Sprint Goal

Now it’s clearer. The goal is NOT necessarily to do the “thing”, but to get the value.

The Sprint Review

Now I will NOT only interrogate the Sprint on whether or not you have “delivered the stuff”.

I will ALSO ask if by doing so, we’ve achieved the expected value (and let me insist that is The Most important question to ask during the Sprint Review…)

The Acceptance Criteria refinement

I reckon this part gets more subtle and difficult. What should be considered as “acceptance criteria”?

Two behaviours usually emerge (and both complement each other):

• Acceptance conversation helping to refine “the thing”
• Acceptance conversation helping to refine “the value”

So, where should we, as product development team, show those things we need to do to deliver that “stuff” ??

The Sprint Backlog

And there we go… we have our “to-do list”.

The dev team meets and plans the delivery of those product hypotheses.

And they build their Sprint Backlog.

With the things they need to do.

With the granularity they need, and agree upon.

Full stop.

Whenever I’ve seen those things mixed, I’ve observed behaviours tending to:

• Business disengaged very quickly, as they just don’t understand the language
• Teams are scrutinised and / or micromanaged by men-in-the-middle
• Reviews end up becoming “reporting meetings”
• Busy work is created
• “Product” becomes something that is not delivering the expected benefit
• Eventually, the program stops

And by the way, don’t blame product management only on these behaviours.

Because…

As a developer,

I want my product backlog to be business meaningful

So that I keep on having a good work

(bad joke… I know…)