On one of my online information hikes recently, I came across this question: Is backlog refinement (grooming) waste?.
Summarizing and paraphrasing, the question asks whether backlog refinement should be abandoned in favor of practices that prevent the backlog growing to a size where refinement would be needed.
RubberDuck’s answer is utterly useful as he not only addresses the ideal situation, but also the road they traveled to get there.
The TL;DR: version:
I agree with you that, once you’ve got a grip on your backlog, that grooming is wasteful. Spending time breaking down requests that will never be implemented is waste and violates the spirit of “Maximizing the work not done.” Delay breaking things down until the last practical moment (but no longer!) and you’ll need to do very little grooming.
However, you have to get control of your backlog before you can get to a point in your journey where that’s feasible.
RubberDuck’s idea of capping the number of epics on the backlog, forcing the PO to remove low priority ones when a more important one needs to be added, sounds good. When team and PO’s manage to stick to the number of epics constraint, it will certainly make the development team’s life easier and they will spend a lot less time on refining items that won’t make it onto the backlog.
Somehow though, I don’t think it addresses the basic issue at work that led to the backlog growing to unmanageable proportions.
Because, while the developers are now insulated from the influx of ideas for the product, what about the PO’s?
They are still stuck with a daily growing mountain of suggestions. And now none of them even get a rough estimate to use as input in their prioritization.
I bet that they’ll simply create another list of items somewhere. A sort of shadow backlog. One they will keep to themselves. One in which they will once again lose the forest for the trees as it grows out of proportion.
It’s basic psychology at work. Fear of missing out, I think. People don’t want to forget a good idea, because they might then miss out on the benefits it provides. So they write it down somewhere. The irony being that as the pile grows, they’ll forget it anyway, because they won’t be able to find it again.
Back to square one, me thinks.
Why is it that people feel a need to hang on to every suggestion ever made for their product? Sure, like I said, you don’t want to forget good ideas. That, however, assumes that every suggestion is a good idea. Of course it is a good idea in the eyes of whomever made the suggestion. Does that make it a good idea for the product as well though? I doubt it.
37 signals approach to feature requests is about the only thing I know of that can prevent that forest of ideas from germinating in the first place: Start with no.
Make saying “No” not just what happens to happen to suggestions.
Make saying “No” your explicit default.
It’s clear, direct and honest as Jason states.
And no, you won’t regret them.
As David mentions “It’s incredibly rare that I’ve actually regretted saying no, but I dread my yes’s all the time.”
When “No” is your default answer to suggestions and feature requests, how do you decide what does get on the backlog?
Well, you need a clear vision of what your product is and perhaps even more of what your product is not; of what kind of customers you are and are not serving.
When you don’t have a clear vision for your product, or when you allow short term financial goals to dictate your product’s direction, you will fall prey to the “oh yeah, that sounds good / fun / interesting, let’s build it” or the “we need to make payroll, let’s build X to get customer Y” disease and your (shadow) backlog will show the symptoms of it.
Tell me, what does the backlog look like for the product you work on?
Leave a Reply