Introduction
Over the past few years, I've had the opportunity to inspect numerous backlogs. Based on these experiences I was able to create a short list of rules on how to handle the backlog in a more effective way. My personal goal was to replace a bit of the everyday chaos with more clarity and aiding Product Owners in maximizing the value of their products.
Fundamentals
What is a Backlog? Based on the Scrum Guide, a Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.¹
In short, a backlog is an ordered list of todos, prioritized to ensure the most valuable items are tackled first, thereby creating a clear pathway towards the product goal and value realization.
That said, by definition, a backlog is a prioritized list that should be constantly revisited and revised by the Product Owner. This continuous refinement ensures the development of a product that aligns with the envisioned goals. Moreover, the backlog serves as a value-maximizing stream, always mirroring stakeholder needs in relation to the anticipated return on investment.
Backlog Safari
Now, for the amusing part. I'd like to share with you some of the most interesting backlog approaches that I've encountered in the wild world of Agile.
The Backlog backlog
I once had a gig where the Product Owner established shadow backlogs to organize his stories, and therefore, his own thinking process. He didn't just have one backlog; he had four of them, each with a prioritization marker on it. For instance, "Backlog 1 - High", "Backlog 2 - Low", and the most interesting one, "Backlog 3 - Not Relevant". In the end, the Product Owner had multiple backlogs to manage but was still unable to make the right decisions.
Support prioritization of Backlogs
What are you going to do if you are unable to prioritize your backlog? Right, you implement things such as tags and custom fields! Back in the day, there were two Scrum Teams, both working with one product backlog. To manage the team separation, they created placeholder user stories like "Team A Backlog Start" and "Team A Backlog End". All of Team A's topics were placed between these dividers. That was the first attempt to manage the backlog. After that, they established a new custom field called "Priority" and created a classification from "4 - very low" up to "1 - very high". But they didn't stop there, they also implemented tags for each team and a tag to indicate if it was a backend or frontend topic.
At this point, there's not much more to say. It was simply the most ineffective approach I've ever encountered.
The Pit
On the other hand, the 'pit' is a fairly common mistake. The Product Owner attempts to keep everything and throws it into this large pit known as the backlog. Each planning session turns into a disaster, with the Product Owner constantly trying to remember what the next thing to tackle is.
The Estimation Monster
The 'estimation monster' often arrives hand in hand with the pitfall of over-planning. It's not just that you have 100+ tasks in your backlog; each task carries an estimate as well. Some of these estimates are months old, leading to the development team's frustration as each sprint fails to reach completion.
The wholly plan
The 'whole plan' is a common mistake too. The idea is to plan the entire application upfront, fill the backlog with hundreds of items, and then lean back and let the other people do their job. Hmm, this reminds me of the good old waterfall days, where each and every project was successful thriving this approach.
Best Practice
So, what have I learned from my foray into the agile wilderness? My experiences can be distilled into a few, but highly effective rules:
Aim to populate your backlog with items that cover a time span of, at most, three sprints.
Prioritize your backlog on a regular basis and make use of techniques like backlog grooming.
Only estimate the tasks you intend to tackle in the upcoming sprint.
Always keep tabs on the needs of customers and stakeholders, and consider the Return on Investment (ROI).
Conclusion
To sum up this blog post, I want to emphasize: Please take care of your backlog. There should be one backlog for one product, nothing more. The established methods to prioritize and order your backlog items are effective, and very often, you don't need anything else. If you recognize any of the backlog pitfalls mentioned in this post within your team, don't hesitate to call them out and assist your Product Owner in maintaining an excellent experience.
Source:
¹ https://scrumguides.org/scrum-guide.html#product-backlog
Top comments (0)