bugzilla-agile

Posted by on 18 Jul 2011 Go to original comments

Bugzilla is cute but deadly.I'm not a pure Agilista™ but we're always trying to improve our development process for MDN. John and I like Scrum and XP stuff, but every team does Agile™ a little differently - as they should. A while back we shopped around for tracker tools and stuck (as Mozillians always do) with bugzilla. We - i.e., mostly John and Jay - also looked at acunote, planbox, scrumdo, agilezen, pivotal, and agilebench.

What we most like about Bugzilla:

  • Bugzilla is Mozillian - it channels the work of tens of thousands of Mozillians; we can cc anyone in the community on a bug
  • Bugzilla is open - we can link anyone in the world to a bug
  • Bugzilla is versatile - as Jonath says in Bugzilla for Humans, it's the devil we know

On the latter point, I've forked some agile features onto Greg's BugzillaJS to help us work more Scrummy™. Our most pressing issue is managing releases - our scope keeps bloating and our releases keep slipping. So we're starting to use the Agile/XP concept of "points" to estimate bugs, track our team velocity, and hopefully improve our release rhythm and reliability. Behold our improved "sprint backlog":

MDN™ 0.9.9 Sprint™ Backlog™

There's a few new things going on here. Here's a summary of how we're doing what we're doing:

Bugzilla Agile Target Milestone
Milestone releases - We use the milestone field of bugzilla for our releases. Next up is 0.9.9 scheduled for August 2nd release. As we move to a more continuous development and release cycle, the milestone version numbers lose meaning (just like Firefox), but we want to track releases. (Sorry James, we're not deploying every check-in just yet).

Bugzilla Whiteboard
Whiteboard overloading - We're using a tag=value pattern in the whiteboard to add new "fields" because adding fields and values to bugzilla requires IT changes and they're over-worked as it is. In our case,

  • 'u' - the primary user of the feature/bug (faster and more programmable than writing "As a ___, I want ___" every time
  • 'c' - the component that the feature/bug modifies
  • 'p' - points

bugzilla agile story points

Calculating points and stories - For any search that includes the "whiteboard" column with the specified tokens, the addon sums the number of "Open" and "Closed" stories and points for the release.

MDN Components Graph
Pretty graphs - data visualization FTW. Seriously, graphs give us a quick snapshot of the open v. closed bugs, and in which component we're spending our effort. This is important for MDN because we want to re-write the wiki while continuing to deploy site enhancements and changes. Now we can see exactly how much of our effort is going to the wiki as compared to other components.

I really hope this improves our releases and makes life easier for devs. Points by release and components are our most pressing needs so we can set realistic release and product expectations, and keep ourselves honest about where we're spending our effort. We'll probably add velocity and burndown charts once we finish a few point-based releases.

If anyone else wants to use it, my fork of BugzillaJS is up on github; download the .xpi file and open it with Firefox to install the addon. Feedback and pull requests are very welcome!

Edit: I should point out we're inspired by other agile Bugzilla tools - the Songbird team has wrestled bugzilla into their Agile process, and fligtar created moxie to help AMO product management.

Question or comment about this post? Tell me on GitHub.

bugzilla-agile / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
mozilla mdn greatest-hits
  1. Kumar McMillan 2011-07-18 16:25:22 -0500
    At my previous job we did XP (when it was the hotness), then Scrum, and we used all sorts of tools. So I've been doing Agile with a capital A since 2004 then stopped at Mozilla. The latest tool I used was Pivotal Tracker and I liked it a lot. There are a lot of rules to Scrum and I don't think it's very useful for remotely distributed teams (although there are published adjustments you can make). However, I think the best concept that everyone should adopt from Agile/Scrum is this: Time does not slip. Ever. If you always release at the *same time* then you guarantee new features to your users. The idea is that you release every week or at some regular interval (called a sprint). The features you actually release depend on what you were able to get done in that sprint. If a feature was not ready for release then you don't release it but all other finished features go out. Another powerful lesson you learn from working like this is that you are forced to *cut* unnecessary features. Cutting features is the secret to doing more work with fewer resources. addons.mozilla.org is in the early stages of moving to continuous deployment. We would essentially release a feature as soon as it's ready and any feature still in development would be hidden behind a feature flag. This would have a similar affect of delivering value to users at a rapid pace but it wouldn't help to force feature cutting. Pivotal Tracker has a really interesting UI where it shows you how many features you'll be able to release at the end of the current sprint to facilitate feature cutting. If a project manager gets ambitious and piles *more* features on the current sprint then features at the bottom of the list will roll off. You cannot bend time! This is implemented using a point system; the backend estimates how many points the team will complete based on a running average calculated over the last two to three sprints. This would be a nice feature in bugzillaJS and I think all each team would need to do is diligently adopt a whiteboard value like points=N (or p=N if you insist). The rest of the effort would be in tallying up previous point values, logging time based milestones, and actually building the UI that showed a projection of what features will go out next. There is probably a way to apply a similar radar for feature cutting to a continuous deployment model but I'm not sure it would look the same. Even without a UI, this is a concept all developers can apply in their daily lives. That is, whenever you're assigned a bug be sure that bug has a clear indication of what value it provides to the user of your product. If it does not explain user value then the bug is either missing information or isn't valid at all.
  2. Lincoln 2013-02-24 17:00:26 -0600
    Hey! Quick question that's entirely off topic. Do you know how to make your site mobile friendly? My website looks weird when viewing from my apple iphone. I'm trying to find a theme or plugin that might be able to correct this problem. If you have any suggestions, please share. Appreciate it!
bugzilla-agile / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA