I've just spent the last 9 hour taming our backlog, which was awesome fun. Not! To give me inspiration, I re-watched this Business of Software video by Intercom.io's Des Traynor on the subject of managing feature requests. Highly recommended:
Backlog fatigue
Before I started, we had around 280 open issues in our GitHub issues list, some of them assigned to a backlog milestone, others posted by users which weren't assigned to a milestone. Most of these were suggestions, or features that we thought would be great to do someday, so we just threw them into GitHub. When suggestions came up in discussions or on the forums, we'd say:
Thanks! I can see why that would be a useful idea. I've added it to the backlog.
It builds up so quickly! And I'll be honest: aside from items in the current milestone, I just avoided looking at any of the other issues - there were just too many. The problem with backlogs is that once they reach a certain size, they suddenly become infinite. Once something has been in the backlog for months, and it gets skipped over every time you do an iteration plan, it's just never going to get done, so it gets bumped and bumped again. Yet every time you plan the next iteration, there they are, just another thing to read and skip over.
I really wanted to have a high-level roadmap of where we're going for the next 6 months, as well as a detailed list of things we're doing in the next few weeks, but making sense of any of that was flat out impossible when the backlog was in this state!
Reclaiming the backlog
I took a deep breath and decided: I will hide from my backlog no longer! I made a plan and decided to draw a sharp line between things we are absolutely going to do, and suggestions. Here's the rules I came up with:
- If it's something we absolutely intend to do in the next two months, it is in GitHub issues (the backlog)
- Everything else goes to UserVoice
9 hours later, I emerged, tired and weary, but ultimately victorious:
- There are 21 open issues in our current milestone, planned to be done next week for pre-release
- There are 56 open issues in the next milestone
- There's a small handful of unassigned issues that I'm waiting on replies to
- That's it. No more!
Items that were so small that I could fix them in the code faster than responding to them got fixed right away and pushed. For everything else, the slow part was searching either for an existing matching item, or copying and pasting things into UserVoice, then typing the reply to say the suggestion was being moved in a personalised way.
In fact, I even changed the way we use milestones. Previously we had a milestone for the current iteration (e.g., 2.4) and a milestone for the backlog. Now, we just have a 2.4 and a 2.5; anything else will be on UserVoice.
Conquering the fear
I was actually quite scared of doing this. Suggestions are hugely important to us and they really do drive the direction of the product, and I didn't want anyone to think their suggestion isn't appreciated, or that we don't care about what they need from the product. We do care.
Yet the truth is, we already have enough suggestions, that if we just picked the most popular ones, we'd have at least 6 months of work ahead of us, let alone looking at the suggestions with just one or two votes. I'd be lying to try and keep everything in the backlog, as if it were all going to get done next week.
Why UserVoice?
Instead of having 200 suggestions in GitHub, we now have 200 suggestions on UserVoice. Does it really make any difference? Well, I think it does:
- The Issues list implies an item will be done soon. UserVoice implies it might be done. I think it's more honest.
- UserVoice issues can be voted on. That makes it easier for us to see what's important.
- I need to read every issue on GitHub every time we plan a milestone. By contrast, with UserVoice, I can just read them when they come in, or only when they start to become popular.
Now, I wrote last week about how votes aren't everything. A lot of the items on UserVoice have pretty good existing workarounds, even some of the highly voted ones. We're still going to add extra priorities to things that we think solve a real pain point and don't have a good workaround.
Balancing strategy vs. demand
Some companies do a terrible job at managing suggestions. Not to name names, but Microsoft have a tendancy to leave items on Connect for years, only to close them as "by-design" when they are clearly bugs. We don't want to do that - every iteration we need to deliver improvements that people want and need.
Of course, we also have a vision for where the product needs to go in the long term, and it's important to balance that with suggestions. We've put together a high-level roadmap for the next 6 months, which I'll publish this week. Each item in the roadmap also exists on UserVoice. Whether they get any votes or not, we will do them, but if some seem very popular we'll let that influence when they get done.
Ideally, we release new versions of Octopus every 2-3 weeks, and I'd like to see each release contain a healthy mix of:
- Bug fixes (we'll always aim to do them first)
- Community suggestions
- Our roadmap items
We're hiring!
We're lucky to have a new developer starting in a couple of weeks (I'll announce it then), but we're looking to grow even more. If you're an Awesome .NET Developer, get in touch! I think we have enough exciting work for you to do :-)
