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":
There's a few new things going on here. Here's a summary of how we're doing what we're doing:
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).
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
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.
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.