The Product Backlog

Wow! What a lot we have accomplished thus far. We've taken a product concept for a simple todo application and iteratively broken it down into smaller and smaller pieces arriving at a while set of user stories that can be used to plan development activities.

This pile of user stories is called the product backlog and this chapter will briefly discuss the product backlog as it relates to Agile development.

What is the Product Backlog?

"The agile product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product." (Source: http://www.mountaingoatsoftware.com/agile/scrum/product-backlog) So it is the collection of the all of the user stories, and epics (plus possibly more) that were developed during the Agile planning process.

The backlog is prioritized, meaning items at the top of the list should be built before those lower down because of technical dependency, logical dependency, and most importantly, business need.

There are some key features of a good product backlog:

It's Visible to Everyone

The backlog is not a tool for one part of a development organization, it should be visible to everyone to best facilitate collaboration and planning.

It's the Single Source of Truth before Software

The backlog and the items in it represent the single source of truth about a product before it is transformed into software (after which the software and its associated tests become the source of truth.) The backlog items override any wireframes, design mock ups, or long form documents.

It's Dynamic

"The product backlog is a living artifact and is never complete. At the beginning of its life it will only contain the best understood requests. As the teams learn more about their customers and the marketplace in which the product will operate, the backlog will continue to change for the better. It’s very normal to identify new items, remove items that are no longer considered valuable and to morph existing items. The product backlog lives for as long as the product lives." (Source: http://agilebench.com/blog/the-product-backlog-for-agile-teams)

What Does the Backlog Look Like?

The actual physical backlog can take many forms depending on the tools that your team uses. It could be a real series of story cards attached to a cork board. It could also be digital story cards in an agile planning web application. Or it could be a simple Word or Excel document. The use of modern agile planning tools help a backlog be visible, and easily editable.

What is in the Backlog?

As we mentioned before, the backlog predominantly contains the user stories and epics that define the product. However as the product develops, there can be other "items" that are typically added and prioritized in the product backlog:

• bugs - A description and work task related to a defect.
• chores - Product work that must be completed, but with no direct business value, these are often reserved for technical tasks to support development.
• spikes - A work task representing "proof of concepts that help provide information for decision making around whether some functionality may be valuable." (Source: http://agilebench.com/blog/the-product-backlog-for-agile-teams)

It's important to keep the backlog focused as much as possible on delivering end user value, which will translate into business value.

The backlog can be considered the ultimate output or artifact of the Agile planning process that this book has described. Once you have worked through each stage of the planning process and arrived at a well specified backlog, then you really can begin to start writing software. The backlog items will clearly describe the features that need to be written, and will be organized such that you can quickly and continuously deliver working valuable software.

What's Next?

Now that you are well versed in the Agile planning process, let's review all this material by showing examples for a slightly more complicated product. We'll tackle that in the next chapter!