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.
The best thing to do is not create a user story until you're relatively certain that it's going to be implemented at some point in the near future.
First, I'll share my vision for my team, then the reality of where we started and how to got to our current stage of our journey.
- Epic/Feature/Story structure to the product backlog.
- Work one Epic per team at a time.
- Cap the number of Epics. Once you hit that cap, PO must remove a low priority Epic from the product backlog. (It's okay, if it becomes important later, it can be re-added. Truly important things will come back up naturally.)
- Epics are not broken down into Features until they're the next priority and the current Epic is nearly finished.
- Features are not broken down into Stories until they're the next priority.
This delays work and decisions as long as possible, while leaning out the grooming process. You can't groom things that don't exist and any grooming that does need to occur, can happen during the prioritization process. That feature isn't as important as you used to think? Scrap it. No big deal. We've no sunk cost in it yet.
Capping the number of Epics/Features in the backlog keeps it from ever growing large to begin with. It also highlights how limited a resource your developers really are and facilitates the prioritization process. It really forces the PO to think about what's really, actually important. You can't have every feature you come up with on a whim. We need to focus our efforts on what brings us and our customers the biggest value.
But like I said, that's an ideal my team hasn't actualized quite yet.
Where we started:
Huge, unorganized, unprioritized, garbage heap of every thing anyone ever asked for. All of it in a few hundred stickies stuck to my boss's office wall. I shit you not.
The steps we took:
Lots and lots and lots of backlog grooming.
- Moved the mountain of stickies out of our manager's office and into a public space.
- Did a rough grouping by area of the business. (Marketing, Quality, Shipping, etc.)
- Determined who could answer questions and make decisions about each area. (Established product owners.)
- Attempted to discover what each sticky was about at a high level. If no one could answer "What is this?", the sticky was thrown away. (Literally, crumpled and thrown away.) Again, don't panic, if it's actually important, someone will ask about it again.
- The team made a "best guess" prioritization.
- Individually, held initial prioritization meetings with each PO.
- Made the prioritization meetings recurring.
- Started entering new requests as stories in our electronic tracker (TFS, Jira, whatever you've got). They also got a sticky on the backlog with an issue number written on them.
- Determined which items were bugs and tried to reproduce them. If they could be repro'd, they were entered into electronic system and its number written on the sticky. If it couldn't be reproduced, we threw the sticky away.
- Started putting effort into entering remaining stories into electronic tracker. Numbers, again, written on stickies as they were entered. After several months of a couple hours a week, everything was digitized, but the physical board remained. Again, if no one could answer "What is this?", it was trashed.
- Identified all current projects and entered them as Epics. Attached related stories to them.
- Identified upcoming projects and entered them as Epics. Broke down top priority Epics (top 3) into Features only.
- Started grouping loose stories into Features and Epics, starting with currently WIP Epics. This did involve a handful of placeholders for "miscellaneous, stories that aren't really part of a project" Epics & Features. Stories were "right sized" and turned into Epics/Features as the team saw fit during this process.
- Discontinued use of physical board.
- Team works with PO to break down current Epics into Features and Stories. POs prioritize Epics & Features. Team prioritizes and pulls stories within the top priority feature as they see fit.
- Desperately try to convince POs that if an Epic is consistently their lowest priority, there's no sense in having it on the backlog, because it will never get done. It's a manufacturing company, so we've had some success explaining that a backlog is inventory and inventory is waste. Not a lot of success, but some.
The process I described has taken us 9 months. We've still a way to go, but we have been able to reduce the backlog's size and convince all of our POs that there is absolutely zero sense in breaking down and estimating Epics (even Features) that we may never actually implement. Added bonus: there's is infinitely better visibility for both the team and our stakeholders about how much work is in the queue, being done, and has been done.
- Convince POs that it's okay to remove things from the backlog that we'll never actually do.
- Put a hard cap on the number of Epics & Features in the backlog (per area).