{"id":2512,"date":"2012-03-27T08:34:11","date_gmt":"2012-03-27T16:34:11","guid":{"rendered":"http:\/\/blog.mozilla.org\/webdev\/?p=2512"},"modified":"2012-03-28T05:19:26","modified_gmt":"2012-03-28T13:19:26","slug":"scrum-and-bugzilla","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webdev\/2012\/03\/27\/scrum-and-bugzilla\/","title":{"rendered":"Scrum and Bugzilla"},"content":{"rendered":"

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<\/a> 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.<\/p>\n

Enter Scrum<\/h2>\n

Being software developers, many of us know and like Scrum<\/a>. 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:<\/p>\n