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.
2 comments:
Debian do this with their Bug Squashing Parties (BSPs). When approaching a release they run these to get the number of RC bugs down.
http://wiki.debian.org/BSP
I agree that this could be a good use of sprints. For instance, bzr currently has 1733 open bugs, around half of those ever reported and more than are marked "Fix Released." That's quite a lot of pain points, though I feel many were transient, since fixed or extreme edge cases.
[ Hey, this would be a better conversation if LP produced graphs of these numbers over time. ]
Bugfixing often requires you to do feature work, or at least re-architect some area, so discussions around the best way to do this would be good for sprints.
Also, there is a question of how to pick the bugs, for Debian it is quite easy, there is a list and all must be dealt with, what should other projects do? Work from the top of the list down in terms of priority?
I think it would be good if tags were used extensively, so you could look at all the bugs related to “dirstate,” or “log,” and try and fix swathes of bugs in one go. Also, if all bugs had executable test cases then you would get TDD for free.
Or, in short, “I agree.”
Thanks,
James
I think part of the problem is that two sprints a year is too few. On the Landscape team we do things a bit differently: we have 4 sprints a year and each one is 2 weeks (so maybe they're more like marathons). We distinguish planning sprints from coding sprints and generally interleave these two things.
We've aligned our development process with Ubuntu's 6 month cycle, so this works quite well. We get together at UDS for a "planning sprint" where we work out what we want to accomplish in the next six months. When we get home we all start working on whatever features have been discussed. These sprints are also a great time to review development process and other non-coding aspects of the project.
Typically in the middle of the 6 month cycle we have a "coding sprint". These sprints are usually about moving forward whatever tasks we've been working on, but sometimes they focus on other things like getting the client prepared for release, or stabilizing code that's been undergoing a lot of churn.
We divide these 6-month cycles into 1-month milestones. One of the ways we deal with bug accumulation is to explicitly use the 6th milestone as polish/bug fix time.
Post a Comment