The "Product Backlog" – What Is It?

First, let's define the product backlog.

The Scrum product backlog is a list of all the things that must be done for a project. These items can be just about anything, from technical items, to issues with the customer or user. The product backlog is the responsibility of the product owner, and the ScrumMaster and the development team contribute to it.

The use of the product backlog doesn't mean that the development team isn't able to build and use other artifacts, such as prototypes or UI guidelines. They complement the backlog, but add additional detail.

The product owner uses the product backlog during the sprint planning meetings, and will list the prioritized items on the list. The development team will then select which items should be pulled off the product backlog and put onto the sprint backlog. Putting an item on the sprint backlog indicates that the team will complete the task during the upcoming sprint.

The product backlog isn't just a glorified to-do list, as each item must have certain properties to land it on the list. These are:

1. The item adds value for the customer.

2. The items on the backlog are ordered, with most important listed first.

3. The most important items have the most detail.

4. All items are estimated.

5. The product backlog is a living document and ever changing.

6. None of the items are low-level tasks.

1. The item adds value for the customer. – Every item that is added to the product backlog must bring some value to the customer. Otherwise, it is a waste. Examples of items that could be on the backlog are:

• Customer needs

• Technical options

• Functional and non-functional requirements

• Work yet to be done

• Setting up product environment

The task cannot add value to the feature, but can still add value by improving quality or customer satisfaction.

2. The items on the backlog are ordered. – All items on the backlog must be prioritized and listed in order from most important to least important. The product owner prioritizes the list with the assistance of the team, and then the product owner must decide what task should be done next.

3. The most important items have the most detail. – Each task will have a certain level of detail. Tasks that are intended to be tackled during the next sprint will have the most detail and supporting information. The reason for this is that spending time detailing info that might not come to fruition is a waste of time and resources.

4. All items are estimated. – All tasks listed in the product backlog must be estimated, according to the story points. These estimations can help with the prioritization.

Key Terms!

User Story

In Agile software product development, a user story is a short description of what the user of the product needs in order to do his job. It provides the development team with the "who, what, and why about the need for the product.

Story Points

Story points are measures used by Scrum teams in order to gauge how difficult a story is.

5. The product backlog is a living document and ever changing. – The product backlog is a living document that changes throughout the product development process. When information changes, tasks are changed accordingly. No information is frozen through the whole development process; instead, the information and requirements change iteratively, along with the software.

6. None of the items are low-level tasks. – Lower level tasks will not have as much information. The Scrum team and product owner determine what information is provided. If the team eventually decides the low-level item needs to be re-prioritized, they will add information and move it up the list on the product backlog.

Grooming the Product Backlog

Backlogs can get pretty messy, especially if they are left unattended for a long period of time. Like a bed of flowers, in order for them to grow correctly, they must be properly groomed, and groomed often. This is an ongoing process that is composed of the following -- although not always in this order:

• New items are found and described, then existing ones are revised or removed.

• Product backlog is prioritized, with the most important tasks at the top.

• Top priority tasks are prepped for upcoming sprint planning meetings, and are refined beforehand, if necessary.

• The team assigns a size to each backlog task. When new tasks are added to the backlog, existing ones are revised or corrected, sizing is required.

The product owner is the boss of the backlog, but it takes a collaborative effort of the entire team to groom it. The team is responsible for finding, describing, refining and discarding tasks, and the Scrum methodology allows up to 10 percent of the team's time to devote to grooming the product backlog. This is all done face-to-face between the development team, the product owner, and the ScrumMaster.

Development teams often find grooming the backlog to be a fun activity, as it gets the team talking and is a great way for the team to get the stakeholders involved in the process. It removes the divide between the business people and the engineering people, and allows the entire team to use their collective knowledge to groom the backlog.

Some development teams do some grooming after the daily Scrum meeting, while others set aside time weekly. The team can also groom during the sprint review meeting, when they are discussing how to move forward. New backlog items can be added, and older ones removed. Teams should groom at least weekly, as a well-groomed backlog is required for a sprint planning meeting to be successful.

How to Structure Backlog

The product backlog have can hundreds (even thousands) of tasks on it, and organizing those tasks into size and relevance is one of the most important jobs of the product owner.

The size of a work item should be comparable to how far in the future the product is planned. This is called the planning horizon. If the planning horizon is long, the work items should be larger. If the planning horizon is short, then the work items should be smaller. This should be obvious, since it takes longer to maintain a long list of small items, than it does to maintain a short list of long items.

Smaller tasks and work items are usually made by breaking down larger work items. The unit of software design is the story.

The Product Backlog Using DEEP

Product backlogs can have hundreds of items or more, and the way it is composed is best explained using the acronym DEEP.

Detailed Appropriately

Estimated Appropriately

Emergent

Prioritized

Detailed appropriately – Tasks and work items must have the proper amount of detail, with the most important items having the most detail.

Estimated appropriately – Tasks and work items in the backlog must be estimated correctly, or to the best of the team's ability. It is understood that, in the beginning, when the task is new, it will be more difficult to give a fair estimation.

Emergent – the product backlog is ever changing -- it is not static. It can change based on customer feedback or changes in the target market. As new items are added, existing items are changed or refined.

Prioritized – tasks and work items in the backlog must be prioritized, with the most important tasks at the top. These items should be numbered from most important down, #1, #2, #3, and so on.

Estimating Tasks and Work Items

In order to understand the size of the items of the product backlog, it is necessary to provide high-level estimates. This helps when it comes to prioritizing where the items belong on the product backlog, and whether or not the possible features are worth the team's efforts.

Estimating the Product Backlog in Points

So, how does the team make this estimate? The best way is to use points. In Scrum, they do NOT use units of time; they use Scrum points. It is actually easier for a development team to estimate in terms of size, rather than in terms of time. It is easier to ask, "How big is it?" than it is to ask, "How long will it take?"

For example, think of a time when you had to write a large paper in high school. You were aware of the work that needed to be done, but you had no idea exactly how long the paper would take you. It is the same principle in Scrum when estimating for the product backlog.

Product owners are clear that what the team provides is simply an estimate of size, not the time it will take to complete the feature.

Discovering Work Items

Discovering items for the product backlog begins with making sure the backlog is fully stocked. This is done with the entire team, led by the product owner. When thinking of what to add to the backlog, don't overthink and add every possible item.

When working on the backlog, keep your focus on the minimum functionality that is required in order to bring the product to market, and remember to keep it simple. As the product cycle continues, more items will emerge and the backlog will grow.

It is almost impossible to focus when starting off with a long and complex backlog. It is overwhelming, and it is difficult to prioritize. Make sure the product vision is used to guide the team through this process. Only tackle the items that are crucial for the project, and don't add too much detail too quickly.

The low priority items are large and "coarse-grained." They stay this way until there is a change in their prioritization.

When the product backlog is done, there will be many chances to discover and find new items and tasks. These will emerge from everywhere, including daily meetings and customer feedback. New tasks will be discovered during the daily Scrum meetings, as well as during the normal course of the work day.

When an item is added to the backlog, the team must understand how that item relates to the needs or wants of the customer. The team must know why the item is necessary, and in what way in helps the customer.

Never copy requirements into the product backlog…as this make the list inconsistent and unreliable. All existing requirements should be seen as liabilities, not assets. Requirements are product functions that were thought to be necessary at some point during the vision or development process. These can and will change as the development team learns more about the customer, or gains more knowledge about the technology involved.

Describing Work Items

Scrum doesn't define how a team should describe the items in the backlog, but most adherents to Scrum use user stories. User stories tell a story about the customer that will be using the product. In the story, a name is assigned, and the story has a narrative that is honest and realistic.

A story can be "coarse-grained," or detailed; these types of stories are called epics. They are easy to write, and the team is free to use whatever technique works best for them. If stories are used, not every item on the backlog must be used. Some backlog items are better expressed using a mock-up or a prototype.

When working on the backlog, the development team can use artifacts in addition to stories. Many teams use diagrams, storyboards, prototypes, and spreadsheets for the complication calculations. The artifacts don't replace the backlog -- they just help better explain the information and content. This creative process is often very helpful for the collaboration of the team.

Themes

Product backlogs can benefit when work tasks are grouped according to themes. These themes act as placeholders for the feature; they add structure, help with prioritization, and make it simpler to find information. An example of themes for a cell phone could me e-mail, voice mail, text, etc.

Each theme should have anywhere from two to five requirements listed alongside it. This will provide the team with enough information to begin. Themes build a hierarchy in the backlog, which also has groups, and then the individual items. The team should also distinguish between large epic requirements and smaller stories.

How To Organize Backlog

The product owner is responsible for the product backlog, and with the development team, they choose which tasks to remove from the product backlog, and place on the sprint backlog for the upcoming next sprint.

When determining how to best organize the backlog, and how the stories in the next sprint backlog should be organized, we use the acronym INVEST.

Independent

Negotiable

Valuable

Estimable

Sized Appropriately

Testable

Independent – Each story must be independent of each other. They are each a different function, and they never overlap each other.

Negotiable – Each story in the sprint must be open to negotiations, and be able to be clarified by the product owner and the development team.

Valuable – Each story in the sprint must offer value and benefit to the customer, the team, and the stakeholders. Almost all product stories offer value to the customer.

Estimable – Each story must be able to be estimated by the development team. The team must be able to estimate how long the story will take using story points, and traditional time units if necessary (hours, days, etc.). So all stories are estimated in story points.

Sized Appropriately – Each story must be sized so that it can be completed in one sprint.

Testable – Each story must be able to be tested. One story can be broken into several testing tasks, such as design, code, support, etc. When completing the testing, the tasks must be SMART:

Specific

Measureable

Achievable

Relevant

Time-Boxed

Prioritizing the Backlog

The product backlog is useless without proper and precise prioritization. So the development team, lead by the product owner, must rank each item in the backlog. This will tell them which stories to focus on, and which are at a lower priority.

When deciding how to rank work items in the backlog, the product owner and development team use the acronym DIVE.

Dependencies

Insure Against Risks

Business Value

Estimated Effort

Dependencies – Minimize the dependencies as much as possible. For example, if work task A depends on work task B, then work task B must be ranked higher than work task A.

Insure against risks – Teams must be careful to minimize risk, both business and technical.

Business Value - What is the value to the customer and the company?

Estimated effort – How long does the team think the work task will take?

Product Backlog to Sprint Backlog

The product backlog is the list of all tasks, items, features and stories for a product, and it is prioritized based on importance. Throughout the development process, items are added and removed from this list, which is managed by the product owner and worked on in collaboration with the development team and ScrumMaster.

The development team in story points estimates the items on the product backlog, which is how it is estimated in relation to other stories. As these stories get closer to the development stage, they are broken down into smaller, more manageable tasks.

The sprint is a two-week development cycle in which a development team produces a potentially shippable product. During the sprint planning meeting, the team will choose some of the items from the product backlog and use them in the next sprint. These items are then moved from the product backlog to the sprint backlog.

At the end of the sprint, all of the items and stories from the sprint backlog should be completed. Then the ScrumMaster leads the next sprint planning meeting, where more items are taken from the product backlog and put onto the sprint backlog.

This process is repeated until all of the items are completed on the product backlog, or until the product owner determines that the product development is over.