In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.

In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:

1. Normally vague/dynamic
2. Completely vague
3. Massively dynamic

The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.

The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.

Normally vague/dynamic product backlog

In an ideal world the product owner can fully populate the product backlog and the developers can estimate every item on the product backlog. I’ve never been in that ideal world.

In messy reality there are always:

• items that can’t be estimated with the information available
• items that nobody spots until latter in the project
• reasons why the business might radically change direction

But there are also some well understood requirements.

This means that a normal product backlog is populated with a couple of months of fairly well understood requirements and then it all gets vague. Requirements come and go from the backlog. That is all fine. Just manage what you know. As time moves on you will gain understanding of the requirements enabling you to keep enlarging the well understood part of the product backlog. You will also develop trust with the customer by continuing to release high value features.

It is a bit trickier for those operating in the context of a project, with fixed deadlines, scope, cost or whatever. If that applies to you then you need to do Agile Project Planning. For me this is all about release planning. You have to turn your prioritised product backlog into a levelled release plan with estimates. Your release plan should include all the user stories you know about. The well understood user stories will have pretty good, and small, estimates and should congregate towards the front of the release plan. The later user stories will have a fair few epics with very big estimates. There will also be some items that you can’t estimate … just make sure they are at the end of the release plan and that you have sufficient detail before the development team needs to know what to build. There is a good chance some of the epics will evaporate before you get to them. Level all of that using velocity corresponding to how fast the development team turns out the user stories. Finally, keep the release plan up to date with new information. New estimates, new priorities, new backlog items, revised velocity data.

Completely vague product backlog

Jo’s specific issue seems to be with having a set of defined product backlog items going into sprint planning. This suggests there are no well understood requirements and the entire backlog is vague.

Now that is a problem. My experience is that if the product owner isn’t clear walking into sprint planning then the entire time is filled up with defining the requirements. That is a not a very efficient way of going about requirements definition.

A better model is that product owner and members of the team meet the week before in a requirements grooming session. I’d include the project manager / scrum master and a technical person but different teams do it differently. This small group are helping the product owner nail down enough user stories to take to sprint planning. It doesn’t solve the bigger problem of why the entire backlog is vague but it does keep the team developing.

If the requirements aren’t clear enough to run a grooming session then there is a huge problem with product management. I’d escalate as high as I could with a view to shutting down the project or changing the product owner.

Massively dynamic product backlog

I’ve also had a massively dynamic product backlog with an external customer. I had a release plan with two week sprints and at the end of each sprint we’d deliver what we committed to. But the surprising thing was the product owner would then change all of the user stories in the rest of the release plan. He changed absolutely everything. Every two weeks!

I didn’t object. I just handled this the way I always handle Agile Project Planning – I created a revised release plan. Every two weeks. Priorities from the product owner. Estimates from the development team. It only took three sprints (six weeks) for the customer to realise there was a problem and where it lay … with product management. I wasn’t party to the conversations behind the scenes but the product owner quickly settled on a product direction and we went back to a normally vague/dynamic product backlog.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.