What is the Product Backlog?
Agile project management uses many different tools and techniques to successfully complete projects. One of the tools used by most Agile project teams is the product backlog. The product backlog is arguably the most important artifact of the Agile project. The product backlog is a prioritized list of all of the work that remains to be done on the project. The product backlog may take any number of forms but is, most often, in the form of a list of user stories. Throughout the project, as required work is identified by the project team, user stories are created and added to the backlog. The word “backlog” often has a negative connotation. However, in Agile, this is not the case. In an Agile Scrum Team the Scrum Product Owner is the owner of the product backlog and manages it throughout the project. However, the scrum team and the scrum master all contribute to the backlog.
Characteristics of the Product Backlog
Since it is such an integral part of the Agile project, the product backlog must be carefully managed throughout the project. There are several characteristics of the product backlog which are important to understand:
1) The product backlog is a living document – items are added, changed, and/or removed from the backlog throughout the entire duration of the project.
2) All backlog items should be estimated – this is done in the form of user points which measure the effort required to complete the backlog item (as opposed to hours or man hours)
3) All backlog items should be prioritized – prioritization may be based on risks, benefits/value, costs, or estimates (story points) and ensures the most important items are completed first
4) All backlog items should add value to the project – if items are determined not to add value, they should be omitted from the backlog
5) Backlog items may have varying level of detail – as iterative sprint planning occurs and items are selected for the upcoming sprint, these items will often have a more granular level of detail than other items
How do We Build the Product Backlog?
At the onset of the project, the project team will almost never have a neat and well-defined list of requirements from which to begin the project. The Scrum Product Owner, Scrum Master, and Scrum Team develop a set of ideas and requirements needed to complete the project. These ideas may be written down on notecards, dry erase boards, or various software applications. These ideas are often scattered across a wide range of product functionalities and characteristics. Because of this, the team must incorporate these ideas into an organized list so that they can start to estimate tasks and develop a prioritized list. This is done by creating a user story for each idea in the following format:
“As a type of user, I want functionality so that reason.”
Each idea will be used to create one or more user stories to which additional detail will be added throughout the project as these stories become clearer and more defined. Managing these user stories and how they fit into the backlog is the role of the Product Owner.
Once all of the initial ideas have been converted into user stories, the team will estimate each story to determine the level of effort needed to complete them. There are many different techniques that may be used to estimate the user stories. Cost and time to complete play large roles in various estimating techniques in which the larger the number assigned to a user story, the more it costs, and/or the longer it takes.
Once all user stories have been estimated, the team can then begin prioritizing the stories. There are many techniques available for determining priorities. The team must weigh stakeholder/customer demands with risk, value, and the estimate of each user story compared against the others to determine the priorities. The highest priority item is at the top of the backlog and subsequent user stories are then listed in descending order.
The below chart represents what part of a product backlog may look like:
| Product Backlog for New Payroll System | |||
|---|---|---|---|
| Task ID | Story | Estimate | Priority |
| 4 | As a user, I want to enter my work hours so I can make sure I get paid on time | 5 | 1 |
| 2 | As an administrator, I want to approve timesheets so employees get paid | 4 | 2 |
| 3 | As a user, I want to log in to the system so I can perform payroll functions | 4 | 3 |
| 1 | As a user, I want to log off of the system so no one can enter erroneous information in my account | 4 | 4 |
| 6 | As an administrator, I want to run consolidated payroll reports so I can provide a weekly status to senior management | 10 | 5 |
| 5 | As an administrator, I want the ability to create new accounts so we can add employees after they’re hired | 7 | 6 |
| 8 | As a user, I want the ability to edit my timesheet so I can correct any mistakes | 5 | 7 |
| 7 | As an administrator, I want the ability to set automated reminders so employees will verify and sign their timesheets on time | 9 | 8 |
| 9 | As an administrator, I want the ability to archive timesheets so the organization can file them for audit and tax purposes | 15 | 9 |
Using the Product Backlog
Once the preliminary product backlog is built, the team can begin using it in their iterative sprint planning and sprint execution cycles. As we previously stated, as the project evolves and the team discovers more requirements, new user stories will be added and the product backlog will continuously change. This is a normal occurrence and not the result of any shortcoming in the team’s planning.
Sprint planning sessions will determine how many user stories the team believes they can accomplish within the upcoming sprint. This will depend on the capabilities of the team and the estimates of the next user stories in the priority order. While the product owner has the ultimate responsibility for managing the product backlog, the entire team provides input to the backlog, as well as determining how much work can be done from the backlog for each sprint iteration.
Carefully managed product backlogs are integral to successfully completing a project and delivering a product. The backlog requires frequent input from all team members as well as stakeholders/customers. Frequent interaction of the team and stakeholders/customers is one of the tenants of Agile methodology. This ensures that the customer helps the team throughout the planning and execution of the project and receives the product it wants.