Your Backlog Is Not A To-do List
This post is inspired by a series of excellent write ups focusing on backlogs and the problems that come with the traditional approach of using them including this one. It should be a personal reflection on how to keep a lean backlog.
There seems to be the perception that the productivity of a product owner is measured by the number of features that get added to the backlog. At least this is the impression I get when reading and hearing about huge backlogs with hundreds of stories.
We don’t measure the productivity of a software engineer by the amount of code he pushes to the repository. Rather the contrary is true, the more experienced and productive the developer, the less lines of code probably, just because we expect experienced and productive developers to follow the DRY concept and other best practices.*
* Well, yes there are companies that use Lines Of Code as a metric for efficiency, but then these companies might also have other pending issues, which means we can ignore them for now.
The backlog seems to encourage non reflective feature adding, everything gets dumped in there, a bunch of high priority features, side stories, bugs, improvements etc. You might get the feeling that resource and time are not a constraint here.
I have read theories encouraging the development team to add features, leaving the product owner to prioritize them. In general the idea sounds perfectly reasonable, as the team should normally have strong insights into the product. But everyone adding every possible feature that comes to mind into the mix will probably lead to the contrary — if the backlog is not maintained properly.
The hardships of dealing with large product backlogs is that they work against the idea of a minimum viable product, because they quickly start distracting from the overall vision.
Just imagine having to keep an overview of a hundred or so features locked in a backlog. First this is hard to maintain from a product owner point of view, where more and more features are being added to the log but only a couple of features being implemented on every iteration.
This would mean the log is getting bigger on every cycle in a worst case scenario. Secondly, the more stories the more time the team has to invest in staying up to date on what is in the pipeline. Obviously this makes no sense. We are adding stories that will probably never end up getting implemented, distracting from what we really need to focus on.
“Adding an idea or a potential awesome feature to the backlog is way easier than designing, building, delivering, marketing & maintaining it.”
Less Is More in this Case
Managing the backlog can quickly become close to impossible or simply counterproductive. We want to avoid this scenario early on. Grooming out of control backlogs will either come with large costs or will at some point be fully neglected, rendering the benefits obsolete.
Identify which features and stories should be removed from the backlog. The product owner must validate the existing stories and remove any unnecessary features. Preferably by consulting and discussing those backlog items with the team.
The important part here is to tackle the problem from the start, meaning quickly validate any newly added stories. Best case would be to always validate all the stories, otherwise this will quickly turn into hoarding features without really evaluating the value they add to the product.
Another important aspect to keep in mind is that there is a huge difference between adding a story to a backlog with twenty as compared to a backlog of hundreds or even thousands of items. Adding item #1290 seems like adding, well, item #1290 to the long list — no real value to be perceived here.
Another possible problem with large backlogs is that it will also slow down the creative process all along. Do we need that many items to create a successful minimum viable product? We probably don’t, we might be adding more features than the customers will ever need or use.
Quick Summary
- Keep questioning if the backlog items are adding business value or just seem cool to have. There is a huge difference.
- Decide what features should be removed from the backlog early on.
- Make sure their is a product owner that is dedicated to keeping the backlog up to date. If not, a Scrum Master might have to push the product owner for dedicating time on the matter.
- Stop adding every feature straight to the backlog. There are features that should be written down, others might be quick or random ideas or simply cool side features that might not make sense tomorrow. Maybe iterate on an idea before adding it to the backlog.
- Stop adding full fledged stories disguised as improvements, this leads to even more confusion and bloats the backlog. As soon as improvements start popping up all over the place, make sure to stop this habit in its tracks.
- Collaborate within the team to keep reflecting on the vision and the current backlog. At the end of the day this is a team event, meaning the team implements the product, also meaning that it is in everyone’s interest to keep things as lightweight as possible.
Links
Originally published at busypeoples.github.io.
