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.
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.
Edit 3/28: Added links to Slumber, Epio, and jQuery.
Fred Wenzel wrote on :
Paul McLanahan wrote on :
Michaux Kelley wrote on :