I think that in many ways the product backlog and the product owner role are Scrum’s weak spot. Scrum brings order to the development process and sets clear demand on the specifications input into the development process. That helps to make visible what we developers have known all the time: It isn’t our fault that projects screw up, because we can’t do a good job on bad requirements. So with Scrum having helped to make the requirement problem visible to everyone it’s time to address the requirements handling.

In my current project, there are a number of distinctive steps that a product backlog item goes through.

1. A new request from someone is noted as a product backlog item.
2. The PO decides to trash it right away, or to go forward with more detailed analysis.
3. The PO (or a BA helping the PO) makes an analysis.
4. The product backlog items is presented to the developers in a backlog grooming meeting.
   • The developers have questions and send the item back for further detailing.
   • The developers approve the item and make an estimate of the entire product backlog item.
5. Only items approved by the developers are eligible for inclusion in a sprint at the sprint planning meeting.

To keep track of this process we use a Kanban board.

The Kanban Board

Our Kanban board has four columns, which maps to the process outlined above.

1. New
2. Investigate
3. Requirements Done
4. Backlog (or Requirements Approved)

When an item is first added to the backlog it is put in the new column. The product owner decides if it’s even worth to put any effort into investigating the request at all. If it is, then it’s moved on to the investigate column. That is the “work in progress” column for the product owner and business analyst. When they think that they are done, they move it over to “Requirements Done”. Once that column contains 10-20 items (we don’t have a hard limit) it’s time for a backlog grooming meeting where the developers look at the product backlog item. If the developers think that the product backlog items is clear enough to be able to work with, they move it to the final “Backlog” state. The development team also gives a time estimate at this point (we use hours and not story points).

If the developers on the other hand think that there is something missing in the product backlog item description they send the item back to the Investigate state, together with a list of questions that need to be answered.

The Sprint Planning

When it’s time for the sprint planning meeting, only those items that are in the “Backlog” state are considered. We use JIRA and I’ve actually filtered the board we use for planning so that it won’t even show items that have not yet reached the backlog state.

At the sprint planning meeting very little time is spent discussing what the items really mean – that has already been done during the product backlog grooming sessions. The focus is instead of getting a list of prioritized items from the product owner to move into the sprint. At this time the product owner has the time estimates on a product backlog item level. With the cost known and the benefits for the business known (the PO should really know the benefit for the business) it is possible to make an informed decision on whether an item should be done now, deferred to a later sprint or perhaps isn’t worth doing at all.

Get the Backlog Process Under Control

With an efficient development team thanks to the scrum practices it’s more important than ever to make sure that a backlog is produced that give the developers the information they need to be efficient. Trying to manage the backlog without proper tooling support or without a clear idea of how to get all those items into a detailed enough state is hard. It is even impossible for all but the smallest project.

If we spend so much time to improve the development process I think it should be natural to also look at the process that leads up to the development phase. Unfortunately I think it’s quite rare to a have a well defined workflow for getting items into the backlog. In my experience that work is often done in an ad hoc manner, which I think is wrong.

I’ll continue with my Kanban board to make sure that the product backlog management doesn’t degrade to an ad hoc work flow. It is evident just after only a few months that a proper product backlog management process with good tool support helps.