Decentralize your Backlog
Ideas are cheap. They come up all the time and end up in the backlog. Remember, really important ideas almost always come back.
Whenever I have been onboarded on an existing product my biggest challenge arrives on the day I get introduced to the product backlog. Irrespective of the size of the product, the backlog almost always is massive.
Over the last decade and a half of working as a product manager, I have come to the realization that backlogs are a big weight we as individual PM's need not carry. Hundreds of items (I have seen thousands) pile up week after week. Some of them will never see the light of day. And every time my management looked at the backlog, I would get a reminder about how slow and behind we are.
“We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details – the pieces of functionality we’d like to build. In my head, I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.”
“After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag – then cut down the tree.”
“That’s what a flat backlog is to me. A bag of context-free mulch.”
~ Jeff Patton
I read this paragraph in Jeff Patton's book on User Story Mapping, and this has been etched into my brain ever since.
In my early days as a product manager, I was given the task to prioritize the backlog. After a few months I realized that backlogs are just a big fat time wasters. I have spent countless hours reading, reviewing, grooming, reaching out for context, organizing this bag of context-free mulch.
Ultimately, you pick up stuff you have context on, or received a million emails and remindres on that one feature that everyone is complaining about or someone's gut feeling.
The root problem starts with someone having an idea that ends up in the backlog - and we almost always have too many ideas. Grooming your backlog becomes hard because:
- Most ideas suck!
- We can't tell which ideas are good.
- We are always over-confident about our own ideas.
Decentralize your backlog
Basecamp's Shape up method/process talk about decentralizing your lists.
We don’t have to choose between a burdensome backlog and not remembering anything from the past. Everyone can still track pitches, bugs, requests, or things they want to do independently without a central backlog.
I'm not saying get rid of your central backlog - we are creatures of habit and a suggestion to retire the backlog in your organization can get you in trouble.
Instead, I wrote a simple script that I use to maintain my own decentralize list. Since there is almost always a massive backlog to refer, I simply used the unique ID, title and a vote field to begin with. Now, instead of looking at a mammoth size backlog, I manage my small list and I add a vote every time someone refers a particular feature. It is important to keep this list small. A good rule of thumb is to identify your team's capacity and maintain 2 cycles worth of items in your list.
Imagine, if every team - developers, QA, etc. maintained their own list of small backlogs. So when it came to planning your next cycle, you can pitch items that you want to pick up that are important, plan out your release cycle without spending the entire agile cycle trying to groom your backlog.
Ideas are cheap. They come up all the time and end up in the backlog. Remember, really important ideas almost always come back.