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 reprioritized, 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.
