How Should Items Be Arranged In A Product Backlog?

By Author: mrugesh panchal
Total Articles: 48
Comment this article

The Product Backlog
The product backlog contains the set of all user stories required to manufacture the product. It is prepared by the product owner on behalf of the stakeholders who actually “own” the product to be developed. The product owner studies and analysis the product, and works out the user stories based upon the functionality to be included in the product. A user story is a product related requirement in scrum. Many user stories constitute the product, and form the product backlog. It is very important to prioritize the user stories in direct relation to their importance and market value. Scrum methodology can incorporate changes occurring in the product related requirements in a dynamic way. Even when the product is actually being manufactured and sprints are currently underway, the stakeholders can still add on new functionality within the product life cycle, and those additions can be successfully added on to the product. The new functionality have to be added to the product backlog before they ...
... can be taken up for development. Moreover, during the sprint planning meeting, the product owner selects a set of user stories from the product backlog, and includes them in the sprint backlog for the actual development to be carried out by the team members.

The product backlog also contains the description of user stories, and strives to explain in what manner the user stories should be developed during the sprint activity. The backlog can also include information pertaining to the various technicalities pertaining to the functionality associated with a user story, in addition to the functional and non-functional requirements needed to understand the user story in the perfect manner. The product backlog forms the “heart” of scrum methodology, and should be carefully prepared in a proper manner by the product owner.

It is worth knowing about the “DEEP” qualities required to create a properly organized and effective product backlog.

The “DEEP” qualities of a product backlog
The four major qualities which help to define an ideal product backlog are:
- Detailed Appropriately
- Estimated
- Emergent
- Prioritized

1. Detailed Appropriately
All the product backlog items should be appropriately detailed, with the higher priority items listed in the beginning or top of the list and the less important items being displayed in the bottom. As per the scrum guide, the more important the product backlog item, the more information it should include, and the less important the item, lesser details should be provided for the particular item. The backlog should be concise – it should only include information which is absolutely necessary and pertinent. Moreover, it is also required to number the items to avoid any confusion from occurring between similar items.

2. Estimated
It is important to include the estimation aspect and link it up with the product backlog items so they can become quantifiable. Story points are used to quantify the backlog items so they can be properly prioritized. A story point is a unit of measurement used in scrum to determine the actual “worth” of a user story. Each item should be associated with a certain story point value when it is included in the product backlog.

3. Emergent
The product backlog should be dynamic in nature i.e. it should be able to include new items as and when desired by the stakeholders and the product owner. It should be stable, and not get disturbed when items are added or removed from it. Moreover, it should allow the items to be shifted up or down in the list, and also allow individual modification of details linked with the user stories contained in it.

4. Prioritized
All the product backlog items should be prioritized. It is also equally important for the product backlog to support re-prioritization of the items once they are indexed within the backlog. This is often required if the nature of the product is volatile and subjected extensively to changing market conditions, in which case the stakeholders might decide to add on new functionalities, or change the priority of existing ones depending upon their needs in the market.