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…)

--

--

--

Driving business goals using agile transformation as the tool to achieve and sustain them

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Art of Co-Creating Great User Stories

How to create user stories

How to Escape the Build Trap?

Is your contracting approach limiting your transformation?

The missing link in IT management; product design time configuration management

Using Mental Models to Create Analogies

What did I learn From Product School?

How to Build Fast Part 1: Team Culture

Writing Your CV to Get Hired in a Product Role

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Carlos Piqueres

Carlos Piqueres

Driving business goals using agile transformation as the tool to achieve and sustain them

More from Medium

How to Understand Your Agile Maturity

Building a good Agile Culture

The Explanation of Agile You Probably Never Heard

Food for Agile Thought #322: Tech Trends 2022, Product Success Factors, Faster and More…