The Significance Of Business Value And The Definition Of Ready In Product Backlogs
Tue 14 Jul 2015 00:10
The product backlog reflects what the clients need in terms of a product release. For a complex or feature-rich product, the product backlog can include a large number of product backlog items, and it can be a huge list. Scrum recommends that important backlog items having high business values should be developed first, followed by less important ones. This is to ensure that the business worth of the project is maintained at all times – even while the team is developing the product.
The product backlog is “owned” by the product owner on behalf of the client. The PO is primarily responsible for creating and maintaining it. The PO can carry out the prioritising activity. Alternatively, the entire team can collectively participate in the activity and aid the PO. Moreover, the PO has a final say regarding the business values to be allotted to the backlog items.
Generally, the PO starts creating and prioritising the backlog when the product release is planned. However, many times, a common issue faced during the initial stages of a Scrum project is that enough information may not be available with the PO regarding what the proposed product features should ideally include. The client may not be clear about, or may need some additional time or information to work out the business values for a set of backlog items. In such scenarios, the PO may merely mention the product features in the product backlog and omit mentioning their acceptance criteria and/or their business value since the information is not available at that time. So, it becomes necessary to update the business value at a later stage when the client avails the required information. This is one of the main reasons why a product backlog item may not be properly defined or prioritised in the backlog.
It is important to prioritise the product backlog so that high value stories are developed first during the daily sprints. So, what is the criterion for prioritising the product backlog? On what basis should user stories or product backlog items be prioritised in a product backlog? The product owner, based upon the product vision seen by the stakeholders and clients tries to prioritise the backlog based on:
Definition of ready
The business value of the user story or product backlog item
One of the main factors to consider while prioritising a backlog item is to determine its business value, and include that value in its definition. The business value is typically a number ranging from one to ten. The higher the business value, the greater is the number. The business value is determined after considering several factors, such as:
Client’s preference and priority in developing the feature
End user requirements
Market demand for the feature
Levels of competition faced from other businesses developing products with similar features, etc.
The product owner assigns business values to the stories based upon the extent of value, or financial worth, the story can bring to the business and stakeholders once the product is developed and released in the market.
Definition of ready
The idea of making product backlog items “workable” or “ready” dates back to the times when the first Scrum guide was launched – in the year 2002. When backlog items are ready, they can be easily called to the sprint backlog for development purposes and converted to product increments. If stories aren’t ready, the development team simply cannot develop the product features. Therefore, it is important to ensure that enough “ready” items exist in the product backlog - at least before the sprint planning meeting event is held.
For a user story or a product backlog item to be ready, it should be:
The item should be properly described regarding what product feature it actually represents. The functioning of the feature should be thoroughly explained so the team can easily understand it. All technical details and specifications i.e. the inputs to the feature, functionality offered by the particular feature, what end users expect out of the feature, etc. should be clearly stated in the story.
In scrum, it is important to complete the development of all user stories accepted in the sprint backlog. For a sprint to be successful, each story should be developed. If a story is too complex, or an epic is not properly decomposed into smaller easily developable user stories, the team may not be able to complete it in the current sprint. The feature should be estimated and split up into multiple parts, if required, so it can be developed during a sprint. It should be feasible to develop the story.
Since Scrum advocates that bug free shippable product increments be developed at the end of sprints, it becomes essential to test the product features developed by the team before they can be released. Each story is assigned a benchmark, or specific conditions, that should be fulfilled in totality before it can be considered as “complete”. When the team develops a backlog item, it is tested against the acceptance criteria or benchmark conditions. Each criteria should be satisfied before the story can be considered as completely developed.