- Agile Bench seems to be one of the most usable and most straightforward products available for managing Scrum projects
- Agile Bench automatically generates burndown charts
- Agile Bench describes itself as being "designed from the ground up to support the key activities that make the difference between your project being a success and a failure." This seems very accurate. Agile Bench is a distilled version of the other tools listed here -- it provides the tools that are actually useful to a Scrum team, and only those tools.
- Agile Bench is not free (as in beer or as in speech)
- Agile Bench describes itself as "a young product with lots of potential." This also seems accurate. While the software does many things very well, it does seem somewhat loose and unrefined. It seems likely that there are gaps that could cause problems for Scrum teams.
- Agile Bench seems somewhat (but only somewhat) buggy. For example, dragging items on the iteration board does not work well in Firefox 4.
- When stories are listed (in the product backlog, in sprint backlogs, etc.), they are cut off after a certain number of characters. The whole story can be read on the "Edit Story" page, but this is inconvenient.
- There is no way to link to individual stories. This might become problematic if we use Bugzilla to track sets of stories.
- Agilo seems very powerful. Users can create tasks, move them into particular Sprints, prioritize them with a drag-and-drop interface, and perform most of the other tasks required for managing a Scrum project.
- Agilo automatically generates burndown charts and other statistics
- Because Agilo is built on top of Trac, it inherits all of the features of Trac (repository integration, etc.). In addition, it can be extended by any plugin that works with Trac.
- Agilo is far from usable. Though this seems minor, it makes the benefits of the software almost a moot point -- it doesn't matter how poewrful Agilo is if no one can figure out how to use it.
Some of these thoughts are based on Songbird's experience with Bugzilla, documented in their post Songbird path to Agility – Part III.
- 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 be marked as dependencies of 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 sdpbot, is released under an open-source license.
- 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 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 hints at this -- the first section is named "Wrestling Bugzilla into shape" and the next sentence explains that the team primarily chose Bugzilla for managing Scrum because they had already been using it.
Note: Scrumbug is a project to scrumify bugzilla
- Like Agile bench, Jira seems very usable and very straightforward
- Jira includes Grasshopper, a tool that provides features useful to Scrum teams. Grasshopper provides a product backlog, sprint backlogs, a burndown chart, and various other statistics.
- Jira is not free (as in beer or as in speech)
The Mozilla Wiki
- Like Bugzilla, the Wiki is already very familiar to the Mozilla community.
- The Wiki is extremely flexible, making it possible to provide most of the artifacts, backlogs, and statistics that Scrum encourages.
- The Wiki's biggest strength may make it a liability for managing Scrum projects. Because it is so loose and unrestrictive, it cannot easily provide a list of "My Tasks", cannot easily track time remaining on tasks, cannot easily provide a burndown chart, etc.
- Open Atrium provides a very good task-tracking tool called "Case Tracker". Case Tracker allows cases to be categorized (bug, feature, or task), assigned, and grouped into projects. Additionally, Case Tracker can send a notification to some or all team members when a case is updated.
- Open Atrium is extremely customizable. Because Open Atrium is based on Drupal, it can even be extended with the thousands Drupal modules that already exist.
- Like all Development Seed software, Open Atrium is extremely usable
- As a beta product, Open Atrium has some design flaws. The notification system is especially problematic, often encouraging users to spam one another unnecessarily.
- Open Atrium's Case Tracker does not allow cases to be assigned to multiple team members. This can cause problems when two or more team members are assigned a collaborative task, as only one of them will see the task in her list of assigned tasks.
- By default, the Case Tracker does not provide fields for time estimates or story points
- By default, Open Atrium does not provide code repository integration as Trac does
- 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.
- Very easy to use. New user can start using the tool intuitively without referring to the user manual or online help.
- Dynamic update of the taskboard in “real time”. The taskboard reflects instant changes whenever user stories are updated or new ones taken up for sprint.
- Some of the features are still missing – they will be available in the beta version to be launched in October 2014.
- Trac makes it easy to generate custom listing of tickets ("reports"). The product backlog and individual sprint backlogs could be created this way.
- Trac does a good job of reporting progress toward milestones. These visualizations could act as a decent replacement for burndown charts.
- Trac integrates with Subversion repositories, and can integrate with most other repository types using plugins. This integration allows team members to browse code and reference changsets in tickets.
- Trac does not provide a burndown chart by default. There is a Burndown plugin, but like many Trac plugins, it is somewhat unstable and somewhat difficult to use.
- Trac does not provide time estimation fields by default. There is a plugin for this, but it is again somewhat difficult to use.