I recently received the following email from Dwight Kingdon at Mindtree:

I’d appreciate your thoughts on “Just in time” Product Backlogs.  I’ve recently run across a couple teams where the Product Owner is not populating the Product Backlog with user stories until just before they will be worked on.  They have themes and epics, but do not break them down any further until a new sprint is about to start.
My thinking is that a robust Product Backlog of “potential” user stories is a good thing, as long as the stories there are viable, and the team doesn’t spend too much time getting into the details until they have moved up in priority to where the value is high enough that they will be worked on soon.  It seems to me that having user stories sit in a Backlog until they either move up in priority or get deleted (due to lack of value) is not harmful, and gives the team a preview of potential future work that they can keep in the back of their mind.
What do you think about a “robust Backlog” versus a “lean/just-in-time Backlog”?  Thanks in advance – I look forward to hearing your thoughts!

It made me think a little more about what I often call effective look-ahead in Product Backlogs. You see I often see this “sprint at a time” approach from Product Owners engaging their Scrum teams.

While it appears lean and agile, I think it puts the team at a distinct disadvantage. There something to be said for a team getting a “coming attractions” view to stories that will land in their laps in the next 2-3-4+ sprints.

Why?

Here are a few reasons:

  • It will give them some time to THINK about stories before they actually start working on them. I would include size thinking, design thinking, and strategy thinking as important aspects.
  • It will allow the team to build stories in their current sprint WITH the future in mind. In my experience this usually helps immensely to reduce rework.
  • It will allow the teams to fully vet each story and have sufficient time to truly get them READY for the sprint.
  • It will encourage (force) the Product Owner to be working ahead of the team on a thoughtful Product Backlog. This includes vetting stories with stakeholders and sorting through priority at a level of detail (below) the Epic.
  • It allows the team to provide FEEDBACK into the stories in the product backlog. For example, efficient construction strategy or preferred testing flow.

And finally, I think it’s just plain respectful.

Imagine if you hired a builder for your new home. Each week you gave them a just-in-time and just enough to-do list for your home. They never knew what was going to happen in upcoming weeks, as you kept them in the dark. I don’t know about your builder, but any that I’ve worked with would revolt against this. They would want to understand the house plans and what you have in mind globally. Beyond that, they’d want some say in how things unfolded in construction steps so that they could effectively coordinate with all of the sub-contractors.

Don’t your teams deserve the same consideration?

Now Back to Robust

Now I’m not saying that the team has to deeply explore every Epic – Story on a product backlog for the next 12 months. That would indeed be wasteful.

I usually recommend a look-ahead interval that aligns with your sprint and release tempo. For example, if you have a 2-week sprint tempo and a 5-sprint release tempo, then I’d expect the teams to be looking ahead from the current release into the beginning of the next release.

And this look-ahead would be realized in the Product Backlog refinement meetings you’d be scheduling as their Product Owner.

Wrapping Up

I really want to thank Dwight for asking the question. If you’ve followed me at all, you know that Product Ownership, Backlogs, etc. are something I'm REALLY passionate about.

I want to recommend some related articles that you might find helpful on this topic:

Stay agile my friends,

Bob.

Comment