The DEEP Method Used For Product Backlog Grooming – How To Prioritize The Product Backlog Items In Scrum

It is very important to prioritize the product backlog from time to time so that it remains updated, and “healthy”. The DEEP method used to refine the product backlog items can be understood as follows:
 

1. Detailed appropriately  

User stories to be taken up for development soon should be properly understood and taken up for development in the upcoming sprint. The user stories which are not to be developed on an immediate basis can be mentioned briefly and described with lesser details.

Generally, the user stories or the product backlog items having a higher priority should be developed first, followed by less important ones. The smaller and more detailed user stories, which a have higher business value should be place on the top, followed by those which have lesser business values and priorities. Epics and large user stories should be broken down in to smaller, more manageable ones, and taken up for development in succeeding sprints. If the entire product backlog is to be detailed in each grooming session, it would take too much time, and even after investing it, the priority can change in the subsequent refining sessions. Therefore, it is not advisable to carry out the grooming session in totality, each time the session is conducted. The objective should be to target the most important user stories based upon the feedback availed from the stakeholders and detail them as per the new priority. The PBIs should be shifted up or down in the order, and larger epics can be broken down into smaller stories and reinserted in appropriate places within the backlog as per the need.
 

2. Estimated
Besides containing the product backlog items or user stories, the product backlog is an important and useful scrum planning tool. It should include estimation in terms of story points for each backlog item.

Estimation is possible in scrum when story points representing the degree of importance are associated with each product backlog item. It is very important for the user stories to have a certain business value associated with them when they are included in the product backlog. The product owner works out how the story points should be allotted to each item in the backlog. The story points, or the estimate is very useful in planning future sprints, and while creating the burn down charts while a sprint is currently being executed. It is essential for each user story to have a priority, at least when they are important, and to be taken up for development on an immediate basis.
 

3. Emergent
The product backlog is dynamic in nature and changes with time as the project develops. AS more information is availed, new user stories can be added, existing ones updated and re-prioritized, and redundant ones removed. 

In practice, a product backlog is never static, and will change over time. As more is learned, user stories in the product backlog can be added, updated, or removed depending upon the feedback received from the stakeholders and investors. Moreover, the development team should carry out routine perusal and remain conversant with the product backlog so they find it easy to understand the user stories when they are taken up for development. The members should demand explanations about items not clear to them, and the product owner is supposed to resolve the queries as soon as possible in a satisfactory manner. The product backlog should complement the vision seen by the stakeholders and the product owner, and fulfill the expectations of developing a shippable product which is profitable.
 

4. Prioritized
The product backlog should be properly arranged as per the priority of the user stories, preferably at all times.
 

Although scrum advocates that each item be properly estimated before it can be added to the product backlog, in practice, this seldom happens. When the product backlog is initially planned, the product owner understands that some of the stories need to be developed because they are essential and needed to complement the product, or make it shippable. However, quite often, he or she fails to receive proper feedback from the stakeholders regarding their importance, or receives it at a later time. In such circumstances, the common practice is to include the user story in the backlog, and wait for further information to pour in so a priority can be assigned for the particular story. Scrum methodology advices this should not ideally be done, and information should be availed to prioritize the item before it can be taken up for development.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

The Purpose And Goals Of Carrying Out Product Backlog Refinement In Scrum

The official scrum guide mentions about carrying out routine maintenance activities to update the product backlog, or to carry out the product backlog refinement. The exact time to be invested in the grooming activity depends upon the management, and how scrum is to be implemented in the project. A rule-of-the-thumb followed is to put in approximately 10% of the time utilized during the sprint activity, into the grooming activity. It is important to be clear regarding some of the aspects associated with product backlog refinement.

Purpose and goals of carrying out the refinement
The primary reason why the product backlog should be refined is to update or rebuild the backlog so that it remains consistent with the requirements provided by the stakeholders with regards the new features and functionalities to be included in the project. Another reason is to review existing user stories or product backlog items and decide whether they are still useful or pertinent from the development point of view, and to update the acceptance criterion and the explanation detailed in each PBI. 

It is recommended to use the “DEEP” method - detailed appropriately, estimated, emergent, and properly ordered – while prioritizing the user stories within the backlog. Larger stories or epics should be systematically broken down in to more manageable smaller ones, proper estimation by assigning relevant story points to the PBIs should be carried out,  user stories should be rearranged as per the new priorities,  and the queries regarding the development of user stories during the sprint should be effectively answered by the product owner. Whenever a meeting is planned to refine the PBIs, the objective should be to carry out enough refinement work so that it lasts for at least three future sprints.

Product Backlog Grooming In Scrum

Duration and frequency of the grooming activity 

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged.

In practice, ideally time equivalent to 10% of the total time spent during the sprint activity should be allotted for the product refinement. For a two week sprint consisting of a total of 6 working hours per day and 14 sprint days per sprint, the time to be allotted should be approximately 10% of 6 hours x 14 days  = 8.4 hours (10% of 6 hours x 14 days = 84 hours). This could be rounded up to one working day. Since the refinement activity is to be carried out on a consistent basis, investing additional time could lead to decreased productivity and an extended product release date – something that should be avoided.  In actual practice, this rule suffices to a great extent.

 
Who should participate in the grooming activity?
Besides the product owner, the grooming sessions should be attended by the development team members and the scrum master. The stakeholders can participate in the sessions too, but their participation should be a passive one, and they should not volunteer opinions, or try to disturb the sessions in any way or manner. Moreover, the product owner should try to limit their numbers during the sessions so it does not become overcrowded and difficult to hold the meeting.

Maintaining a proper approach
It is important to remain focused, and the product owner should be clear whether a particular product backlog item should be estimated again, or it ought to be detailed in greater depth, and additional explanation provided regarding its acceptance criteria. The team members should remain focused upon understanding the PBIs and if required they should demand explanations regarding the acceptance criteria and how the development should be carried out during the sprint activity.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How Should Items Be Arranged In A Product Backlog?

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 analyses 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.
 

A Product Backlog Containing User Stories In Scrum

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:

1. Detailed Appropriately
2. Estimated
3. Emergent
4. Prioritized

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.
 

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.
 

Prioritizing The User Stories According To "DEEP" Qualities

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.
 

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 functionality, or change the priority of existing ones depending upon their needs in the market. 
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!