Product backlog items are also known as user stories, backlog items, or “PBI”s. They represent the product features to be developed in the project. In Scrum, the entire product is broken down into its constituent features and functionalities. Each feature exists as a user story or a product backlog item in the product backlog and developed in product incremental cycles known as sprints. A sprint planning session is held just before a sprint cycle commences. During sprint planning, a few user stories having high business values are selected from the product backlog by the product owner and the team for development purposes. Selected stories are transferred to a temporary development list known as a sprint backlog and developed by the team in daily sprints.
Product owner and backlog items
The product owner or the “PO” owns the project on behalf of the stakeholders. He or she is responsible for the success or failure of the project. The PO is primarily responsible for “designing” the backlog items and creating the product backlog. In addition, the PO has to ensure that the project’s business value or its “market worth” is maintained at all times. It is, therefore, required to associate each backlog item with a certain business value. The PO carries out this activity by assigning story points to each backlog item. He or she may seek help from the Scrum master and the team members if required. During the sprint planning meeting, traditionally the PO selected user stories and created the sprint backlog. However, as per recent market trends and Agile practices, the role of the PO has changed to a certain extent and the development team now aids the PO in selecting user stories, and in creating the sprint backlog. As per Scrum practice, the PO decides the “What” aspect concerning the development of product backlog items i.e. what stories should be developed first. The development team has the right to decide the “How” aspect – how stories selected in the sprint backlog should be developed. The PO has to make sure that the team understands how the stories should be ideally developed and explain them to the team members. If the team has queries, the PO answers them.
Refining the product backlog
The product backlog should reflect a true picture as to how much a particular product feature or functionality is worth in the market. Market conditions are liable to change over time, and some of the features having high business value may lose their importance because end users may no longer need them. On the other hand, stakeholders may request the development of new features to “add-on” to the market value of the product. Since product features are represented through product backlog items, it may be necessary to add new items or remove old items from the backlog. The business value of some items existing in the backlog may be updated depending upon the feedback received from end users. The process of updating the product backlog is known as product backlog grooming or refinement. Grooming sessions should be carried out on a regular basis and the team should aid the PO in this “routine” activity.
Getting the “most” out of an Agile product backlog
The Agile product backlog forms the “heart” of all development activities in Scrum. The product can be developed in time through the sprint cycles if a few aspects are carefully “looked into” while defining the backlog items and taking them up for development during the sprint sessions.
- The business value of each backlog item is properly “worked out” and stated in the backlog.
- The acceptance criteria and the definition of “Done” should be clearly stated.
- The team members properly “understand” the backlog items so they can make informed decisions during the sprint planning sessions (accepting user stories based upon individual experience levels) and daily sprints.
- The correct number of backlog items should be taken up in the sprint backlog for development purposes.
- The team should know how to present the backlog items, after development, to the stakeholders during the sprint review and retrospective sessions.