dzone.

com

https://dzone.com/articles/product-backlogs-practice

Product Backlogs in Practice

agile,scrum,tips and tricks,product requirements,agile management,scrum management
A few days back I came across Yuriy Zubarev's Cynical Agile and Scrum Dictionary. There are some nice, cutting
observations in there, but the one that has really made me smile is:

Backlog: a land of forgotten dreams

Years ago I went to college on the Isle of Skye, off the west coast of Scotland. I learned about Tr na dochuimhne
and other such mystical places of Gaelic culture. These days my perception of the Lands of Forgetfulness is
driven not by any loch-mist that streams through the hills to the isles, but by the forsaken backlogs I find on Scrum
boards. All too often the user stories that are put on a product backlog never make it to reality. All through an
entire project they can sit there, these creatures of whimsy, half-reminding a team of something
which should have been done, or which might have been done, if only they had time to get round to it, or
which could have been looked into, but never was. Each was put there for a reason that the team may not even
remember any more. Perhaps they never really knew why. "Anyway", they tell me, "there have always been other
more important things to be getting on with". The Product Backlog is the land of forgotten dreams.

What a Product Backlog should be

Seen at its simplest, a Product Backlog is an ordered list of requirements, the content and ordering of which is
maintained by a Product Owner representing one or more customers. Each requirement is sized by the
development team, such as by estimating the effort that is likely to be needed to complete it. In an agile method

like Scrum, a portion of those requirements are taken at regular intervals and worked on by the developers who
will then produce something of value. Each interval is known as a Sprint, and the portion of requirements to be
actioned in a particular Sprint is called the Sprint Backlog. The Product Backlog is the set of requirements for the
entire project. The responsibility for managing it lies wholly with the Product Owner, although he or she must
negotiate each Sprint Backlog with the development team. Since the Product Backlog contains requirements of a
given size, and each Sprint Backlog contains some of those requirements which are of a given size, the rate of a
project's progress can be measured.
However, a Product Backlog is never complete because scope and priorities are always in some degree of flux.
That's just fine though. We know that requirements change all the time, but by keeping a Product Backlog
updated we can embrace that change instead of fearing it. With a known rate of progress the impact of such
scope changes on the estimated date of project completion can be foreseen, and stakeholders can modify their
plans and techniques accordingly. These three legs of transparency, inspection, and adaptation underpin an agile
way of working.

When Product Backlogs go wrong

Ironically enough, the seeds of backlog decay are often sown in this very flexibility, and in the willingness of a
team to be adaptable. When a new requirement is introduced there is a very high likelihood that it will be an urgent
one. For example, Scrum teams aren't always dedicated to project work but very often have to provide Business
As Usual (BAU) support as well. This support work will invariably trump development priorities and there is an
excellent chance that BAU requirements won't be put into the Product Backlog at all. Instead they'll be fasttracked straight through to "Work in Progress". In effect the quality of service provided by the Scrum team is
permitted to vary, somewhat in the manner of Kanban. This hybrid way of working is known as Scrumban and by
my reckoning it must be the most widespread Scrum variation to be found in industry today. It's easy to see that if
fast-tracking is left unmanaged, the team will operate in a reactive mode and will never become a truly agile one.
The backlog will fall into a state of neglect.
So whose responsibility is it to manage this unforeseen work? The answer depends upon whether it relates to the
product being developed or to something else entirely. For example, if the project involves the enhancement of an
existing system, it's quite plausible that any BAU fixes will be related to that specific product. The call on
prioritization - to fast-track or to place in the Product Backlog - can and should be made by the Product Owner.
Only that person is authorized to decide on matters of product value, and if a Scrumban approach has been
agreed with the developers, they'll be obliged to provide the quality of service that fast-tracking represents. Clear,
unambiguous product ownership is very important in this situation.
On the other hand, if the team are also supporting a completely different product - or set of products - as part of
their BAU responsibilities, the Product Owner won't be in a position to make the call. Sometimes it's only the team
themselves who can triage BAU requests coming in, although if they are driven through a customer support helpdesk it may be done for them. In either case the team will have to appraise the Product Owner of this fast-track
work. At the Product Owner's discretion, the Product Backlog can then be revised, customers notified, and new
priorities set which reflect any projected impact on schedule. Yet again clear product ownership is important if
backlog management is to happen. Without it a Product Backlog will decay and fall into lost remembrance.

Three tips for avoiding decrepitude

Here are three key measures that will have to be taken to stop a Product Backlog from corroding:
1. Clear Product Ownership. A development team is responsible for what it accepts into each Sprint
Backlog, but ownership of the Product Backlog always lies with the Product Owner. That's the person who
must understand the business value of each item, and who can order or prioritize them accordingly. A
Product Backlog should have exactly one Product Owner. If there is no Product Owner at all, then the
Product Backlog cannot be maintained in an effective and businesslike manner. If there are multiple
Product Owners arguments over priority can arise or ownership can be weakened in order to avoid such
conflict. As the Scrum Guide points out, "Product Ownership is not a committee". A limited degree of
compromise can be allowed, such by allowing a Product Owner to be represented by proxy, but this must
always be treated with caution. Whoever represents the Product Owner must be fully able and empowered
to make decisions regarding product value on their behalf. This is the person who must keep the Product
Backlog up-to-date, and who can account for each item on it so it does not become a forgotten dream.
2. Frequent grooming. The Product Owner and the development team should review the entire Product
Backlog at least once per Sprint. This can be done as part of the Sprint Review although it is also
acceptable (and increasingly common) to arrange dedicated sessions for this purpose. The idea is to give
the team the opportunity to provide or revise estimates for each item on the backlog, and to identify any
issues or ambiguities that might forestall Sprint Planning. The process of grooming a Product Backlog can
be instrumental in keeping it up to date and relevant, and fresh in the minds of all stakeholders. Team
grooming becomes especially important when product ownership is shaky.

3. Collaboration with other teams. Projects rarely exist in isolation, and are more typically components
within a larger portfolio of changes that reflect an organization's strategic goals. Product Backlogs can
therefore be highly interdependent at a portfolio level. This means that teams will need to collaborate with
each other, both directly and through their respective Product Owners, to make sure that release trains are
synchronized and in accordance with compatible Definitions of Done. Failure to collaborate in this way can
lead to the disintegration of Product Backlogs that no longer reflect the intended strategic direction.

Conclusion
A Product Backlog is far more than just an ordered list. There are a range of behaviors that must come together
for one to be effective. These include clear product ownership, a team commitment to review and estimate, and
ongoing collaboration with the wider enterprise. A Product Backlog will not manage itself. It must be subjected to
diligent curation if it is to avoid the journey into the land of forgotten dreams.