Bug squashing sprints

Each of the Launchpad teams gets together in a single location for a week long “sprint” fairly regularly. Maybe each team has two sprints a year.

Often these sprints end up being long talking sessions where designs for features are thrashed out. That’s great and all, and sprints are a rare opportunity to do that, but often the design work goes unused for months while the team deals with the work already on its collective plate.

Sometimes these sprints have the whole team working (i.e. coding) toward a single milestone, be it a release or a major feature. These sprints are fun, but they’ve been quite rare for Launchpad. (Bazaar had a great one in Brisbane earlier this year).

What I’d love to see is a sprint where people fixed as many bugs as possible. Perhaps as a product strategist, I ought to be advocating higher-level visions and responding to the market and so forth, rather than saying “fix lots of bugs”. But I don’t think so, at least, not yet.

Fixing as many bugs as we can in a fixed time frame will make many users happy, since behind each bug is a user in pain. It will make us happy as a team, since a vastly dropped bug count will make us feel less overwhelmed and will feel like a concrete achievement. It’s an easy sprint to measure the success of, and my hunch is that it would be a fun sprint too. It’s also substantially different to what we normally do, which adds to the fun.

What do you think? I’d love to hear from people in community-driven open source projects, as well as people within Canonical who aren’t in Launchpad. Maybe we’re missing something that others know about.