Scrum/Tools: Difference between revisions

Jump to navigation Jump to search

Scrum/Tools (view source)

Revision as of 17:19, 3 June 2011

2 bytes added ,  3 June 2011
Alphabetical order.
(→‎The Bad: Added note about OA's lack of repo integration.)
(Alphabetical order.)
Line 1: Line 1:
== 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 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.
* 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  [https://code.google.com/p/sdpbot/ sdpbot], is released under an open-source license.
=== The Bad ===
* 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.
* The Songbird team uses priorities to create an informal release backlog. Though it can be modified, it seems that sdpbot by default assumes that priorities will be used this way. As the Scrum Guide [[Scrum/Guide#Release_Backlog|explains]], release backlogs are rarely useful and sometimes detrimental.
* 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.
== Open Atrium ==
== Open Atrium ==
=== The Good ===
=== The Good ===


Line 13: Line 30:
* Open Atrium does not provide a burndown chart, and there do not seem to be any Drupal modules that can provide one
* Open Atrium does not provide a burndown chart, and there do not seem to be any Drupal modules that can provide one
* Though Open Atrium is very customizable, many customizations are wiped out whenever the system is upgraded. Though not impossible, building customizations in such a way that they do not interfere with future updates can be difficult and time-consuming.
* Though Open Atrium is very customizable, many customizations are wiped out whenever the system is upgraded. Though not impossible, building customizations in such a way that they do not interfere with future updates can be difficult and time-consuming.
== 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 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.
* 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  [https://code.google.com/p/sdpbot/ sdpbot], is released under an open-source license.
=== The Bad ===
* 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.
* The Songbird team uses priorities to create an informal release backlog. Though it can be modified, it seems that sdpbot by default assumes that priorities will be used this way. As the Scrum Guide [[Scrum/Guide#Release_Backlog|explains]], release backlogs are rarely useful and sometimes detrimental.
* 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.
John Karahalis
Confirmed users
1,193

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/315296"

Navigation menu