Spring Cleaning? Now is the perfect time for agile backlog grooming. The sun is shining; the birds are singing. The tree leaves are back, along with people’s allergies, easily confused with COVID-19. Speaking of COVID-19, millions of people have been forced to stay home over the last few months, and many have started attacking home projects with a vengeance, because they have no place to go except for their local hardware store. Garages have been organized, along with closets, basements, and attics. Yards are now tidied, new flowers and vegetables planted, and the world is generally a cleaner place. The madness even overwhelmed me and I am now the proud owner of a freshly re-graveled driveway (and some seriously sore muscles). Many items on the To Do List have been checked off. Speaking of To Do Lists, (and because I need to get around to talking about agile things) how’s your product backlog?
What is a Product Backlog?
If you are new to agile (Scrum in particular), the Scrum Guide defines the Product Backlog as “an ordered list of everything that is known to be needed in the product.” That includes new features, functionality, requirements, bug fixes, and any other changes to the existing code base. Responsibility for it resides with the Product Owner, but keeping it in good shape requires the whole Development Team. A product backlog in agile/Scrum is never complete. Sounds a lot like the Work Breakdown Structure (WBS) in Waterfall? Yes and no.
Product Backlog in Agile / Scrum: Empirical Process vs. Work Breakdown Structure
One critical factor to remember about Scrum is that it is an empirical process. Empirical is just a fancy word describing a process that is based on observation, experience, and experimentation. Since people using the Scrum framework are learning during each Sprint through experimentation, the Product Backlog in agile/Scrum should be changing all the time. A Work Breakdown Structure, on the other hand, is a static document that shows a hierarchical breakdown of the total scope of work a team has to accomplish. There isn’t specific value in any given WBS task, because there is no release associated individually, so tasks have to be tied together over a long period of time before they have value. In a Product Backlog in agile/Scrum, items in a Sprint become a shippable product increment that is releasable at the Product Owner’s discretion, producing immediate value.
Keeping up with the Evolving Product Backlog
It is not easy to keep up with an evolving Product Backlog. One-way Product Owners attempt to keep it under control is through regular Backlog Refinement (AKA Scrum/Agile Backlog Grooming) sessions with the Scrum Team. Refinement includes:
- adding details (such as clarifications and acceptance criteria),
- estimates (based on effort and risk),
- and priority (based on value).
High priority items that have adequate clarity (as specified in the Definition of Ready) are placed at the top of the Product Backlog, and lower priority items, or items that lack critical details are placed lower. Some items are too large to be completed in a single Sprint, so they need to be broken down into smaller items.
Backlog Refinement can take up as much as 10% of the Development Teams capacity, but a well-groomed Backlog shortens the time needed for Sprint Planning, and increases the chances that the Sprint Goal will be met. The refinement sessions can be spread throughout the Sprint, and can occur as formal meetings, or informal “water cooler” conversations. The best times should be worked out between the Product Owner and Scrum Team (with the help of the Scrum Master). The Scrum Guide is not specific about how to get it done, as much as the importance of doing it. My only advice is to make sure that each discipline on the team is represented (for example architecture, development, QA, and the PO) so all parties have input.
Why Spring Clean your Scrum/Agile Backlog Grooming?
So, why Spring cleaning? Over time a lot of Backlog items are pushed down in priority due to changes in business requirements or market conditions. Experiments are conducted and lessons are learned that help the team realize that there are better ways to accomplish the work, and perhaps some items are not needed at all. This lines up with the Manifesto for Agile Software Development principle: “Simplicity – the art of maximizing the amount of work NOT done – is essential” (emphasis mine). Once or twice a year (or more!) it is worth taking some time to review the bottom of the Backlog (like cleaning out the basement) in order to remove items that are no longer required or relevant. Finding a half dozen items that have already been addressed in other stories, or just aren’t needed anymore will certainly give the team a boost. Who knows? You might even find an item from last year that you were just about to write up.
Thorough refinement keeps agile teams successful. Occasionally grooming the bottom of the Backlog keeps the team sane.
Stay healthy!
Esse quam videri,
John
Up next:
Want to explore some new ideas and techniques for helping your Product Owner and team deliver better received and higher value products?
Watch our free webinar for best practices on A Tester’s Guide to Collaborating with Product Owners. Please apply password, “ZenBox284” to watch.
