Confirmed users
1,193
edits
Scrum/Tools: Difference between revisions
Jump to navigation
Jump to search
→Bugzilla: Added more prominent link to Songbird article.
(→The Bad: Fixed release backlog link.) |
(→Bugzilla: Added more prominent link to Songbird article.) |
||
| Line 14: | Line 14: | ||
== Bugzilla == | == Bugzilla == | ||
Some of these thoughts are based on Songbird's experience with Bugzilla, documented in their post [http://blog.songbirdnest.com/2008/12/15/songbird-path-to-agility-part-iii/ Songbird path to Agility – Part III]. | |||
=== The Good === | === The Good === | ||
* The bug dependency feature seems very useful. Scrum recognizes that a product cannot be fully defined from the start. As a result, Scrum encourages teams to write basic descriptions of distant requirements and add specific details as they become apparent. The bug dependency tool may allow for this. | * The bug dependency feature seems very useful. Scrum recognizes that a product cannot be fully defined from the start. As a result, Scrum encourages teams to write basic descriptions of distant requirements and add specific details as they become apparent. The bug dependency tool may allow for this. | ||
** For example, a team building a website might create a user story for user login early in the project. Without much information, this story would be fairly high-level, for example "A user should be able to log into the site." Later, the team could add specific details as additional stories -- "A users should be able to log into the site with his email addresses", "The user should be able to find the 'Login' link in the top-right corner of the site", etc. These stories could depend on the first. | ** For example, a team building a website might create a user story for user login early in the project. Without much information, this story would be fairly high-level, for example "A user should be able to log into the site." Later, the team could add specific details as additional stories -- "A users should be able to log into the site with his email addresses", "The user should be able to find the 'Login' link in the top-right corner of the site", etc. These stories could depend on the first. | ||
* Mozilla is, of course, very familiar with Bugzilla. Most people would need little training with the tool. | * Mozilla is, of course, very familiar with Bugzilla. Most people would need little training with the tool. | ||
* The Songbird team has written a tool which generates reports from Bugzilla tickets. The tool, called [ | * The Songbird team has written a tool which generates reports from Bugzilla tickets. The tool, called [https://code.google.com/p/sdpbot/ sdpbot], is released under an open-source license. | ||
=== The Bad === | === The Bad === | ||
* The authors of | * The authors of sdpbot note that they "made no attempt to make it generic" and that people using the software should expect to "do some work to customize it" for their needs. | ||
* | * sdpbot does not seem to generate burndown charts from Bugzilla data, and there do not seem to be any other tools that do. | ||
* Unlike some other tools, Bugzilla aims to be fairly generic. It was not built specifically for managing Scrum user stories, so it may take some work, frustration, and training to set it up appropriately. The writeup from the Songbird team seems to confirm this -- the first section is named "Wrestling Bugzilla into shape" and they explain that their primary reason for using Bugzilla was that their workflow was already built around it. | * Unlike some other tools, Bugzilla aims to be fairly generic. It was not built specifically for managing Scrum user stories, so it may take some work, frustration, and training to set it up appropriately. The writeup from the Songbird team seems to confirm this -- the first section is named "Wrestling Bugzilla into shape" and they explain that their primary reason for using Bugzilla was that their workflow was already built around it. | ||
* The Songbird team uses priorities to create an informal release backlog. As the Scrum Guide [[Scrum/Guide#Release_Backlog|explains]], release backlogs are rarely useful and sometimes detrimental. | * The Songbird team uses priorities to create an informal release backlog. As the Scrum Guide [[Scrum/Guide#Release_Backlog|explains]], release backlogs are rarely useful and sometimes detrimental. | ||