A product backlog is a list of things that need to go into a product. Manipulating the product backlog is one of the most powerful ways of controlling an Agile software development project.
The are a number of ways you can manipulate the product backlog.
The first thing that you need to do with a product backlog is put something in it. You can run workshops, you can do user research, you can get ideas in the middle of the night. But in order to have a backlog you need items to put on it. One key difference between a product backlog and a requirements document is that adding things to the product backlog should be nearly cost free. When it’s added to the product backlog, an idea can be just one line. There is really no need for a lot of detail. Detailing the items in the product backlog comes later (see below).
An important difference between a traditional requirements document and a product backlog is that the items in a product backlog can be ordered. Which items are put first can vary greatly from project to project. Sometimes it’s best to do the simplest first, sometimes it’s best to do the hardest and most scary.
Sometimes there is a lot of dependency between items which means that once one item has been prioritised, there’s a clear need for several other items to be done first.
As discussed above, items can - and should - be added to the backlog with very sparse detail. But throughout the development process more detail should be added to the items which have been ordered near the top. How far down the ordered list of items the detailing should go, and how granular the detailing should be will be different for every project.
By tracking the progress through the items in the backlog we can get a rough idea of how long it might take to get through all of the items in the project backlog. If it took us a month to get through ten items on the product backlog we can imagine that it will take us another ten months to get through the remaining one hundred items in the product backlog. Of course this calculation assumes that all of the items in the product backlog are roughly the same size. If we suspect that the items in the product backlog aren’t all the same size we can estimate their size relative to each other and give the large items on the backlog a large number of points and the small items a smaller number of points. This activity can then give us a better idea (it’s very debatable how much better) of how long the entire backlog is likely to take.
If a deadline has to be met there are several ways of reducing the product backlog so that something can be delivered in the time required. It’s not unusual to find that the time that it’s likely to take to get to the end of the product backlog is far longer than is acceptable. In fact, in my experience, it’s not unusual for the calculation to show that the project will take two to three times longer than was hoped, expected or required (the worst case I’ve had direct experience of was a backlog that would have taken seven times as long to finish as was required). If a deadline has to be met there are several ways of reducing the product backlog so that something can be delivered in the time required.
The most straight-forward of these is to remove from the backlog any features which aren’t absolutely necessary for a particular deadline. A more sophisticated version of this is to split the backlog, in effect, into two. A backlog for the next release and a backlog for sometime in the future.
A more involved way of reducing the scope is to reduce the ambition of each of the items in the backlog. For example, if an item in the backlog my be for the login page. And it may have been detailed to also include registration for those not yet registered, mechanisms for prevention of robotic registration, validation of email and password reset. A strategy for reducing a the scope of this backlog item might be to spit the scope of the item into to. The first item would be the absolute simplest thing that could be done to achieve login (a form with username and password boxes and a submit button). The rest of those bits of scope (registration, etc) could then be put in another product backlog item.