| DMZing the Backlog |
| Tuesday, September 16 2008 |
|
Raymond Lewallen wrote a post a few days ago that talked about identifying waste. What I found most interesting in his post was the paragraph about backlogs (excess inventory). You see, at Telligent our product release cycles are broken down into milestones, which are broken down into 2-week iterations. As the release cycle moves along, items get added to our backlog. Lots of items. Invariably, we can't clear the backlog. If we tried to take care of every single item in the backlog, we'd never ship anything.
For example, we're shipping two versions of Community Server this week: CS 2008.5 and CS Evolution. The backlog for CS 2008.5 has 260 items; CS Evolution has 121. That's a lot of items, and in lean terms, it's simply excess inventory; a form of waste.
So now that we're shipping this week, what do we do with all those items in the backlogs? The standard answer is that these items simply fall into the work for the next release, which is fine, but a lot of planning has to take place. You have to go through the lists, reassess/revalidate each item, give them an estimate, identify iterations, assign them out, etc. You also have to take duplication into consideration, because with that many items you're bound to have duplicates, which just takes more time to deal with.
But why didn't these items make the cut into the product? Because they weren't critical to the success of releasing *that* specific version. And that brings me back to Raymond's post where he says "If it's important, it will resurface later". It might be from a customer, from internal dogfooding, or from your CEO; it doesn't matter. What matters is that if it's important, it will resurface later.
Think about that for a second and realize how liberating it is. It reminds me of an aspect of Inbox Zero, where at some point you might have to simply move all your email into a DMZ folder that is used only for archival purposes. The thought behind this is "If someone needed something from me, they'll email me again". That's no different than what Raymond points out in his post about backlogged items. I've done the DMZ thing with my email and admit it's one of the most liberating things I've ever done. And it works because guess what? If someone needs something from me, they'll email me again.
Armed with these thoughts, I sent an email tonight to a couple other leads and PMs asking what they thought about moving all our existing backlog items into a DMZ-like location and seeing what items resurface. It'll be interesting to get their take on the approach, but I'd also love to hear your feedback on this. What do you think? Have you ever done this? If so, how did it work out?
6 comment(s) so far
While our backlogs at my current workplace aren't as large as yours, we still have to deal with the items on the backlog when we come to a release as you stated.
For us, all of our clients are internal ones so this makes it a little easier as we have a tighter feedback loop and thus can eliminate any backlog items that aren't important.
I like the idea of dumping them all into a dmz type location, this eliminates processing time on your end as you don't have to wade through all of the items, and putting them aside until later. I would be interested to see how this works out.
I agree about the liberating experience with DMZing email. I am not so sure that I agree about doing that with backlog.
One of the reasons is the trust relationship between the customer and the company. As a customer (either internal or external), if I've taken the time to report an issue I want to know it's been logged. I want to know that someone considered my input and made a decision on it, even it is a reasoned decision not to act on it. Just sweeping it into a trashcan somewhere and then putting the burden back on me to resubmit it does not result in feel-good relationship. Do this to a couple of customers, and word gets out that all you are doing is giving lip service to the ideal of listening to and reacting to customer feedback.
I think the key phrase on that topic in Raymond's post is "In lean, any backlog item that cannot be identified as a customer need based on actual, current demand, is excess and should be gotten rid of." Actual, current demand. Rather than just dumping the old backlog, why not open up the list to the customer base for feedback and voting? Those items that garner the most attention and feedback are hence identified as actual, current demand. This sort of approach seems to work for Microsoft Connect.
Terri - interesting comment about opening up the backlog list for customer feedback and voting. I can see that being very beneficial.
This reminds me of a 37signals practice:
http://www.37signals.com/svn/archives2/getting_real_forget_feature_requests.php
I now realize that I was considering the backlog in the light of bug reports, not feature requests per se.
A Sketch: Ideation Pipeline