Scrum and Bugzilla

Not all teams at Mozilla follow the same software development methodology. We’re free to design our own workflows, use whatever tools we want, and just generally work in whatever way is best for us. The one component that almost every project uses is Bugzilla for issue and feature tracking. If you’ve ever worked for, or contributed to Mozilla, you have a Bugzilla account. Apart from being a very powerful and configurable tool, this level of participation is a large part of what keeps projects using and wanting to use Bugzilla.

Enter Scrum

Being software developers, many of us know and like Scrum. I’ve personally found it to be a great method of answering the old questions of “How long will this take?”, and “How much can we get done?”. I won’t go into great detail on how Scrum works here, but the main points are as follows:

  • Work units are scored by the team based on difficulty or expected time consumption.
  • Those work units are included in a “Sprint” usually lasting 2 weeks.
  • Lots of interesting data is generated around team performance.

That last point is key. In order to be able to use and appreciate these data, we need to be able to collect and visualize them in a useful way. This normally means awesome charts and graphs. As nice as Bugzilla is for coordination and issue tracking, it has an unfortunate lack of awesome data visualization tools. It does however, have an API.

The Birth of Scrumbu.gs

There have been some valiant efforts at improving the interface of Bugzilla. One of these, BugzillaJS, even adds some pie charts for Scrum data in a bug-list. But what I really wanted was a burndown.

The data you need to associate with a bug (or story in Scrum parlance) are the user who will benefit from the work, the component of the product to be affected, and a score (points) representing the perceived difficulty of the work. Bugzilla has no fields for these out of the box, but a catchall field called the “whiteboard” can be formatted in such a way as to allow tools like BugzillaJS and Scrumbu.gs to easily find it (see below). This is obviously not optimal, but it’s what we have for the moment. And when you combine that with the bug history data from the Bugzilla API, you have all you need to calculate burndowns, team and developer velocities, and all sorts of even awesomer things.

The result of this need, my excellent bosses allowing me the time to experiment with cool stuff, and the existence of Python, Django, Slumber (REST client), Twitter Bootstrap, jQuery, Flot, and Epio (python/django hosting), is Scrumbu.gs. It’s still a work in progress, but you can click through some existing projects and sprints to see how it’s working so far. The code and issue tracker are on github, so feel free to poke around and see how it works. If you see a problem or have an idea for a feature, please file an issue, and if you have the ability and/or desire, send a pull-request :).

I recently gave a lightning talk about the project for my team at Mozilla and I’ve included it below if you’re interested. My hope with this project was to spread the use of Scrum around Mozilla and other teams who use Bugzilla, and to improve the tools for those who already do. If your team is interested in tracking your sprints using this tool, participating in its development, or just chatting about Scrum, please join us in the #scrum channel on IRC.

Download video as MP4, WebM, or Ogg.

Edit 3/28: Added links to Slumber, Epio, and jQuery.

3 responses

  1. Fred Wenzel wrote on :

    This is great, thanks Paul! Using the whiteboard as a vehicle for this data is really smart.

    Does scrumbugs pull in the data on a cron job or something, or is this all done client-side?

  2. Paul McLanahan wrote on :

    I can’t take credit for using the whiteboard in this way. I really have no idea who came up with this use or the data format. I just learned that it was being used for this and dreamed of pretty graphs 🙂

    The data is grabbed from the Bugzilla API on the server side via the excellent Slumber REST client library. It is pulled on demand, and then cached for a set period of time. I did this to reduce the calls to Bugzilla. I wasn’t sure how much this would be used initially, so I didn’t see a point in having it hit the API unless someone was actually interested in the data. At the bottom of each sprint page you can see when the data was last refreshed, and if you really want fresh data before the timeout you can “shift-refresh”, which will tell the server to clear the cache for that sprint.

  3. Michaux Kelley wrote on :

    Nice work! We just started assigning points to tickets at MetaMetrics using redmine. This looks like a tool that would definitely improve our Scrum experience. Sounds like you guys get to work on some really cool stuff there!