iterative backlog management

When the Product Owner doesn’t have enough stories to drive development, try running an incremental analysis project that keeps one iteration ahead of the developers. The deliverable from each analysis iteration is a modified Product Backlog, ready for the upcoming development iteration’s planning meeting.

Whatever the reasons, it’s sometimes a fact that the Product Owner just doesn’t have the backlog prepared in time for the next development iteration. This can have a destructive effect on the development team’s morale and productivity, and must not be allowed to continue for too long. So something we’re trying on a current project of mine is to set up a parallel “analysis” project, to be run using the Scrum process. (This is certainly not a new idea; for example, Martin Fowler talks about this technique in Planning and Running an XP Iteration.)

I expect the mechanics of the two projects to work something like this:

To kick things off, the development team will spend one iteration catching up with technical debt while the analysis team creates the first set of stories. At the end of this first iteration, the analysis team will present their deliverable: an initial Product Backlog populated with high-priority stories. The same day, the development team will hold their second iteration’s planning meeting, using this initial Backlog as the source of stories. At each subsequent iteration boundary the analysis team will present a new Product Backlog and the development team will use it as the basis for their iteration plan.

I expect story creation to proceed more quickly than story development. That is, I expect that in 2-3 iterations the analysts will produce enough Backlog to keep the developers busy for 5-6 development iterations. Nevertheless the analysis project will continue until the product is released, with the analysis team performing the role of Product Owner for the developers.

The Product Owner for the analysis project will be the company’s CEO, who has the overall vision for where the software product needs to be. He has already created the analysis Backlog – a high-level set of product capabilities and market drivers. The analysts will work through these capabilities, feeding in user feedback, market research and general product knowledge and breaking them down into bite-sized stories for development. As more capabilities come to be analysed I expect that their high-priority stories will push into the development backlog, demoting some stories that were analysed earlier, but which have lower business value.

The main thing, though, at this stage is to get the development project up and running again. A steady stream of incoming stories will hopefully kick-start the team again and get both morale and productivity back to where they should be.

2 thoughts on “iterative backlog management

  1. Pingback: energising the iteration review « silk and spinach

  2. Pingback: the product owner must pull (revisited) « silk and spinach

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s