This post covers rationale and practical details about the product backlog. Have a look at the post on scrum basics to put the Product Backlog into the greater picture.
The product backlog is a list of functional and non-functional requirements sorted by importance. It is continuously updated and maintained to represent current customer needs. The product backlog is the plan.
The above self-composed definition should be descriptive enough, but you should also benefit from having read the more elaborate definition that follows.
The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requirements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers. (Definition provided by Mountain Goat Software)
In the following list, I’ll present some of the main benefits we’ve identified of using and maintaining a product backlog.
1) It’s a simple list, discussed face-to-face
This is at the very core of Scrum (and of agile development in general) with it’s focus on individuals and interactions. Throughout the years of software development, several clever schemes have been devised for effective customer communication with a low probability of misunderstandings. It may seem that one format we all can agree on, which is effective and not likely to introduce confusion, is the combination of a simple prioritized list of requirements combined with real life and ongoing face-to-face communication. It’s about as high-bandwidth communication as you can achieve.
2) It provides the customer with control
The product backlog consists of functionality wishes / the what / requirements, call it whatever you wish; it describes what the customer needs. “Allow undo on the article-edit“, “Allow logged in users vote on other users articles” are a few examples of product backlog items. These items are non-technical, and thus graspable even by the customer regardless of his or her professional background. As such the customer is able to participate in prioritizing the items in the product backlog. Discussing the product backlog is the customers main forum for controlling the input to, and thus the outcome of, the project.
The team adds coarse estimates to items in the product backlog. However, as with any coarse estimates, no-one should be held accountable for these estimates (thorough estimates are added when the items are broken into tasks in the sprint backlog). To my understanding these coarse estimates have one main benefit; they help the customer make informed decisions when prioritizing. As stated in the wikipedia article about Scrum : “e.g. if “add spellcheck” feature is estimated at 3 days vs 3 months, that may affect the Product Owner’s (customer’s) desire“.
3) The product backlog is allowed to change.
Most of us have developed healthy allergies towards work that is of little or no value. Attempts to write a comprehensive and detailed plan up front can at best be useful for developing an understanding of the project, but any attempts to follow and/or maintain such a detailed deterministic plan is doomed to fail due to the natural and uncontrollable complexity of software development. It consumes too much time, and it does not lead you to the best results. Don’t do it. Start with the most obvious requirements and let it evolve according to you and your customer’s understanding as time goes. Use new knowledge by embracing the inevitable change.
The product backlog is allowed to change, and thus it is allowed to grow as understanding increases. A topic that we’ve visited several times already, is the very central benefit that the product backlog can also shrink. Understanding and embracing this benefit is imperative for success. Shrinking away items leaves room for growth of new and more important items into the product backlog. (See item #3 in this post for more elaboration on this).
4) Inspection and adaptation
The product backlog is reviewed by the team on a monthly basis. A major benefit of viewing the product backlog as a coarse plan is that these monthly reviews serve as a forum for incorporating new knowledge about the product and its goals into the plan. A major assertion of agile development, and one that it relies heavily on for rationale, is that Empirical Process Control is the only known mechanism that can deal with the complexities of software development. I agree with this assertion. (Software development does not always generate the same output, given the same input.) Empirical process control requires frequent inspection and adaptation. The monthly review of the product backlog at the sprint planning meeting, offers a bit of both. (Scrum offers a lot of opportunities for both, and I’m sure we’ll be discussing this more). At the sprint planning meeting we are inspecting the current state of the product backlog, and consequently adapting our next sprint based on its current state.
5) It resolves dependencies timely, and without fancy pansy dependency graphs.
By putting items that are dependent on the completion of other items below the ones they are dependent on, the dependencies are resolved. It’s that simple, and both the team and the customer can understand it. Given it’s simplicity, it’s likely to be maintained. These dependencies are also dealt with in a timely manner during the sprint planning meeting. When choosing items from the product backlog, you’re likely to choose 5 items from the product backlog, and then add a couple of items that one or more of these 5 are dependent on.
6) It allows for some longer term planning
In contradiction to what I, in true tabloid fashion, wrote earlier about how Scrum Kills Your Plan (but hits your business targets), the product backlog can, with some experience, be grouped coarsely into larger chunks representing future sprints. It will be the object of as much uncertainty as most forms of planning will be (see #3 in the list above), but it allows you to define a path beyond the current or next sprint to add some visualization to the road ahead.
The first Scrum mechanism we introduced in Aptoma was the product backlog. The product backlog, with its mechanisms and related way of prioritizing, its ease of use and level of customer involvment and the way of acting on requirements has been one of the more beneficial introductions related to Scrum for us to date. To fully comprehend all benefits of the product backlog, you’ll have to stay tuned for future posts on the sprint backlog and on sprint planning.