2017 SCRUM GUIDE UPDATE – Sprint Backlog change: “To ensure continuous improvement, it includes at least one high
priority process improvement identified in the previous Retrospective meeting.”.
My first question is: OK… but how could be represented one process improvement
as a Product Backlog Item?
BREAKING SCRUM RULES – one of the most common and ugliest forms it is to consider the Product Backlog as
being formed from user stories. It this your current approach? Is that what
your coach told you? Well, that it is
deeply wrong also according to Scrum creators.
Here it is what Jeff Sutherland
said (see the reference below about user stories): <<Backlog items include
everything the team needs to do in one ordered set of activities >>
and <<Wherever possible, backlog
items should deliver complete vertical slices of functionality across work
layers>>, where this “vertical
slice of functionality” could be very well represented by a user story.
According to the Scrum Guide, the Product Backlog is
composed of Product Backlog Items. What are these Product Backlog Items, if
there is such confusion among the Scrum practitioners (coaches and “masters”
included)?
Back to the Scrum Guide (2017), here are some of its
references to the PBIs:
- <<The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product>>
- <<The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. >>
- <<The Sprint Backlog is the set of Product Backlog items selected for the Sprint >>
- <<The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal >>
- <<The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.>>
The PBIs are part of Product
Backlog, Sprint Backlog, and (Product)
Increment. So, having only the Scrum Guide as a guideline
we can believe that the Backlog and PBIs are a kind of “Product Breakdown”, a
list of deliverables directly related to the product. The “twin” of the product
breakdown is the work breakdown, that organizes
the work in association with related deliverables, not necessarily directly related to the product. So, considering the
Scrum Guide PB is rather a “product breakdown”, but according to above-mentioned quotes from Jeff Sutherland is
a “work breakdown” ~ “everything the team
needs to do”. Why this confusion?
SIMPLIFICATION - The Scrum Guide contains some simplifications that could not offer enough guidelines even for
Scrum creators point of view. The deliberate approach to make Scrum Guide and
Scrum to seems very simple could be
misleading. For example, the Product Backlog was
intended to be a “work breakdown” that “whenever
is possible” should deliver something directly related to the product “vertical slices of functionality across work
layers”. Whenever is possible this work breakdown should be oriented to the
value stream and value delivery, but it is a work breakdown not something else.
CONFUSION AND PROBLEMS - The work breakdown it is confused (by some Scrum practitioners) with a
list of requirements or with the product breakdown. Here are some examples of problems
induced by this confusion:
- Poor estimations without improvement - Estimations are made directly on requirements, without appropriate envisioning over the solution (… and that mean a much higher risk for inaccuracy). In fact, it is even worse: estimation skills are not developed with time because are not correctly exercised
- Forgotten work - The work needed for the release, and not directly related to the product change could be forgotten. That work will be discovered too late and that is a risk for the plans and for the results.
- Life-cycle problems – we could have various agile and lean life-cycles, and all will express the work breakdown. We could have severe problems of understanding of the life-cycle if the team will make the mentioned confusion. For example, the release envisioning will be poorly made because will stopped at the level of requirements envisioning. In other cases, the transition to production is almost forgotten: the team and their collaborators will discover very late in the release significant risks and “unexpected” remaining work.
- Throwing away the alternatives - the Product Backlog has a specific way to model the work (a serialized, ordered list). There are also other ways to model the work in agile or lean manner, as the Work Item Pool (see Agile Modeling references)
ESTIMATION – estimation should be always associated with a piece of work
(for some requirement, fixes, or others), and not directly with
requirements (user stories). We can implement the same requirement in an
unlimited variant of solutions, that could have very different needs for effort and
resources. When you “estimate” a user story, you are estimating, in fact, the work related to that user story,
already having an envisioned solution approach. In fact, you cannot decompose
the functionality into independent
realizable parts if you will not have the “product breakdown” needed to get the mentioned “vertical slices”.
WORK ITEM - The Product Backlog Item (“everything the team needs to do”) represent, in fact, a piece of work (not a piece of the
product, and not a piece of functionality), but with the recommendation to be whenever is possible a direct change
of the product, a direct contribution to
the value stream and value delivery. Using engineering term and not vague
terms, that is “working software” from Agile Manifesto.
If the Product Backlog Item it is
in fact, a work item, there is no
problem to conform to the 2017 Scrum Guide recommendations to “includes at least one high priority process
improvement” in the Sprint Backlog, and there is no problem to “include everything the team needs to do”.
GUIDELINE – If you need a clearer guideline, you can the Work Item List from Disciplined Agile. it is having the
same purpose as Scrum Product Backlog, but without over-simplification: “we know that we do more than just implement
new requirements each iteration, we often do non-requirement related work such
as take training, review products of other teams, address defects (I believe
that defects are simply another type of requirement) and so on.”
More, with Disciplined Agile
you have options/alternatives to the Work Item List as the Work Item Pool (when
working in Lean variants of the life-cycle). In
the same time, the vague concept of “backlog refining” that is strictly related
to existent of the Backlog it is replaced by more generic Look Ahead Modeling.
FINAL THOUGHTS – It is absolutely OK to breakdown you work considering the value stream and the product breakdown as a Product Backlog, but you should also remember that:
- work breakdown is not a list of requirements, and not even a product breakdown (but a subsequent aspect)
- you can always use an Work Item List instead of Product Backlog, but sometime you can use alternatives as Work Item Pool (see Disciplined Agile/Agile Modeling references bellow)
- do not confuse simplifications with the real things and always ask for guidelines about what is behind anything that is simplified by convention
Bibliography and References
- Better User Stories: Have Your Cake and Eat it Too Jeff Sutherland, Joel Riddle, Scrum.inc
- Agile Modeling (Scott W. Ambler) - Work Items List, Work Item Pool
- Scrum Guide 2017
