Why do you want to use a scrum tool? I’ll hazard a guess and say that you have a distributed team. At least, thats the reason Silver Catalyst was written. Co-located teams can use index cards and information radiators, but distributed teams need a better way to communicate (see the pm story).
I was once involved in a project where the customer was in the US and the development team, of which I was a part, was in Singapore. We had agreed upon a schedule and were working to it when one day the customer asked us if we were on track for the release next week. It was a bolt from the blue because our schedule showed the release to be more than six weeks away. After some frantic discussions, it was discovered that the customer was looking at an old release plan, and the schedule had been updated in the interim. Whoops.
Thats the key really. A scrum tool is not for controlling and tracking the project, it is to improve communication between distributed teams stakeholders. The lack of face to face conversations make distributed environments prone to miscommunication, which in turn leads to all sorts of problems in managing the project.
The above example illustrates one common miscommunication pattern: Looking at different versions of the schedule. Miscommunication does not happen only between the customer and developers. It also happens between management and developers and even geographically distributed development teams.
Agile development partially solves the problem by making frequent releases. These releases expose what has really been completed and act as sync points between the development teams and stakeholders.
I say agile development only partially solves the problem because frequent releases just addresses miscommunication between development and customer (or product owner). However, distributed teams often need synchronization within an iteration, and thats where a tool can help.
Somtimes managers and customers are more comfortable seeing a burndown go to zero or the acceptance test pass rate go up, than they are in actually seeing a demo. This often happens when the managers and customers are not domain experts.
To give an example of this, one of my projects was writing a browser for a mobile phone. One of the features we implemented was for float support. Since the customers were not domain experts (they were usually managers), they could not understand what float support was. As long as it was in the specification and it was completed, they were happy. In such a situation, they asked for reports because they couldn’t really figure out anything from seeing the release.
This kind of situation sounds weird — how can the customer not know their domain — but it happens rather frequently. In such a situation, having visibility into the burndown charts is a better option for them, and if they are distributed, you’ll need a tool to make it visible. I’ll probably expand on this in another post, because it turns a fundamental aspect of agile — frequent releases and feedback — on its head.
So those are the two main reasons to use a scrum tool. To summarize, a tool for distributed teams helps
- Improve communication between distributed teams
- Increase stakeholder visibility into the project.