Product Backlog Refinement
Wed 01 Jul 2015 00:10
Product backlog refinement is a routine backlog maintenance activity, and an integral part of the Scrum process. It is important since it helps to keep the product backlog organised, and in proper order. The product backlog items, which actually constitute the product backlog, represent the product features to be developed in the project. Each PBI carries a certain business value. These business values actually define the importance of a particular product feature in the form of product backlog items. When changes occur in the product’s market related conditions, the business value associated with a particular product feature, and its PBI, may change. These changes need to be updated in the product backlog. During a product backlog refinement session, PBIs are updated with respect to their business values, so the backlog can reflect a true picture about how much worth the product is from the market point of view.
Scrum fundamentally concentrates upon delivering business value to the client through the product increment cycles. When PBIs are updated from time to time, some of the backlog items having high business values can be taken up for development in the daily sprints and delivered to the client in the form of shippable product features. This becomes possible when the product backlog refinement process is carried out on a regular basis.
What does the backlog refining activity consist of?
The product backlog is a dynamic Scrum artefact and keeps on changing on a continual basis during the development process. As changes occur in the product features, the details associated with the PBIs have to be updated in the backlog to keep it healthy at all times. The backlog refinement process is directly related to the upkeep of PBIs, therefore it is worth knowing what can be actually “refined” in the backlog:
The description of a product backlog item generally does not change once it is defined. However, at times it may be required to elucidate the PBI by describing it in a more detailed manner. This may be necessary when PBIs having seemingly similar descriptions are to be added in the backlog. Even though the descriptions of two or more PBIs may not be the same, they might seem to be the same at a first glance, and this could create confusion while identifying similar types of PBIs in the backlog. Each backlog items should be defined in a manner such that its uniqueness is understood by reading its description. Refinement process can include updating the PBI description.
2. Acceptance criteria
The acceptance criteria linked with the PBIs plays a significantly important part in defining the Definition of Done “DoD” during sprint planning sessions. Each item has its unique DoD which has to be fulfilled if the PBI is to be considered “releasable”. Many a times, while creating the product backlog at the time of project start-up, the Product Owner may lack certain information necessary to define a PBI in depth. At such times, the PO may simply reference the PBI and define it in the product backlog while keeping other relevant information blank in the PBI to create the project estimate. This is done by estimating the backlog items. The idea is to plan a probable release date for the project. The acceptance criteria is a technical part of the PBI that has to be defined so the development team can focus upon how the backlog item should be developed during the sprint. The acceptance criteria may be updated from time to time as per information availed from the stakeholders and the development team.
3. Business value
The business value is estimated using story points in Scrum. Each PBI has a certain business value linked with it. Business values are important since the framework focuses upon delivering consistent product increments that add on to the project’s worth in the market. One of the major reasons why managements prefer using Scrum for development purpose is because one you can avail important product feature releases from time to time. Moreover, business value of the product is maintained while the features are being developed. Business values may change if the demand of a particular product feature may decrease or increase depending upon end user requirements. When such a change occurs in the market, the business value of the PBI representing the particular product feature should also be updated to reflect the most recent change. During the refinement process the business values of PBIs may be updated.
Who is responsible for refining the PBIs?
The PO “owns” the product backlog on behalf of the stakeholders, and is primarily responsible for creating it. It is not necessary for a PO to create the backlog personally – he or she may instruct the development team and/or the Scrum Master to help him/her in defining the backlog items and in estimating them. The PO is held responsible for the creation and upkeep of the product backlog. Therefore, the PO also oversees the backlog refinement process.
Who should carry out the refinement activity?
The refinement process may be carried out singularly by the PO, or alternately the entire Scrum team may participate in the event. Generally, the development team updates the PBIs (with the exception of business values that should be updated by the PO). There are no specific rules about who should carry out the refinement process. What is important, though, is that the Product Owner is responsible for the upkeep of the product backlog. The team can freely decide who should refine the PBIs.
How frequently should the backlog be refined?
The refinement sessions can be carried out in different ways as per the team’s convenience. The team may spend an equivalent of approximately 10% of the entire sprint time in refining the backlog. Alternately, the team may spend a couple of hours each week, or even half an hour on a daily basis (generally not recommended) and keep on updating the PBIs. There are no fixed rules how frequently the backlog should be refined. However, considering the nature and size of the backlog, the team should unanimously decide how frequent the sessions ought to be. The bottom line is that the product backlog should remain healthy and high priority PBIs should made available for sprint planning sessions.