Product Backlog

The Product Backlog consists of all features, functions, technology, enhancements and bug-fixes that - as they are developed - constitute the future releases of the product.

Completion of the backlog will transform the product from its current form (if it is being enhanced) into its vision. But in Scrum, the backlog evolves as the product and the environment into which it will be used evolves. So the backlog is dynamic, constantly changed by management to ensure that the product defined by completing the backlog is the most appropriate, competitive, useful product possible.

When you look at a product backlog, priority has a perspective. The higher the priority, the clearer and more detailed the backlog. The lower the priority, the less the detail, until you can barely make out the backlog item (very low priority, just a placeholder to remind us).

 

Estimates
Develop estimates of each (e.g. FTEs, cost, complexity, risk, function points) for backlog items. These estimates are more clear for higher priority backlog items (more understood, clearer) than lower priority backlog items. However, developing estimates may cause the priority of the backlog to shift (we can get this done quickly, let's do it first!"). Estimate in days.
Creators
Backlog originates from a variety of sources. Product marketing will generate features and function. Sales will generate backlog that will cause the product to be more competitive or please a particular customer. Engineering introduces backlog that builds technology that holds the whole product together. Customer support enters backlog that represent major product flaws that need to be fixed.
Prioritization

Every backlog item has a priority that gives it a relative ranking of importance relative to all other backlog. The backlog is a prioritized list. "What features, technology, bugs to be fixed, etc. will make this product most beneficial to this product company and to its customers?" is evaluated against "What can we get built most quickly?" to determine. A constant sifting of backlog is done to constantly re-evaluate what is most important against the internal technical environment and the external marketplace, and to evaluate what can be done quickly against what will have the most impact.

Releases

Plan the next several releases by identifying the purpose of the releases and their probable contents (you will probably be changing release contents as you balance features with release date with cost).

Group the Product Backlog that you intend to be in the release. Communicate this with the product development teams so they understand the overall development objectives. Ensure that supporting technology is planned at the same time as the release and is included in the Product Backlog.

Owner

Assign a master backlog owner. This person is responsible for managing and controlling the backlog list. For commercial type developments, the master backlog owner may be the product manager. For in-house development efforts, the master backlog owner could be the project manager or whoever he/she designates. This person is responsible for coordinating the prioritization and estimation efforts of the backlog list (getting the inputs to it) as well as making final decisions of what is to be included or not included in the sprint. This is a collaborative process in which all affected parties have input into it.

Only one person prioritizes work. This person is responsible for meeting the product vision in a way that optimizes product return. The title usually is product manager, or product marketing manager. If anyone wants the priority of work changed, they have to convince this person to change that priority.

Suggestions/Notes:
  1. You may want to consider putting assessing the backlog with some sort of a triage matrix with customer priority on one side and development/test impact on the other. Items with high customer priority and low development impact has the most impact.
  2. Prioritization is an iterative process between the customer establishing the priorities and the development team developing their estimates. For example, once the customer realizes the cost of that feature compared to others, they may change it’s.
  3. Keep in mind that this is a very collaborative process between the customer and the development team. It is meant to be a joint activity, not a negotiation game. The goal is to figure out how to produce the best possible software product in 30 days.
  4. Trying to prioritize and estimate the backlog list may be a difficult thing to do initially during the first couple of sprints but will get easier over time.
  5. All projects have risk associated with them, otherwise they are just a country club outing. SCRUM is an approach to minimize risks because even if a sprint fails to meet it’s goal or the customer decides to scrap the project altogether, the sprint should still be looked on by the customer and management as a success because on typical projects, you wouldn’t be made aware of any problems until 8.5 months down the road on a 9 month project…and after spending a whole lot of dollars.