- Planning process
- Plan visibility
- Plan update
- Velocity tracking, Time tracking
- Burn Down Update and other charts update
- People involvement
Agile Tools Decision Matrix
I've captured Michael's Agile Tools Decision Matrix in a spreadsheet which you can download and modify to suit your needs. Just as an aside, he also stumbled upon a great name for cards, post-its and manual burndown charts: tangible tools. Even though he didn't really use it, I love it! It's succinct and correct, and the inherent advantage of tangible tools just jumps off the page - I will use the term moving forward.
When to use tangible tools
Tangible tools are great for learning the processes and principles. Hung on the wall, they radiate information for all to see. They are extemely flexible for structuring and displaying information. Use them to get started with Scrum. Use them as long as you are happy with them.
I like to use tangible tools for initial planning (getting personae & and first cut at the user stories in a group workshop) and retropectives. In both cases the volume of information which needs to be permanently recorded is small and the flexibility and collaboration requirements for creating the information are high. I would also think about complementing a dedicated tool by hanging burn down charts on the wall: either printouts or manually maintained copies, especially if management is collocated.
When to use Office and Wiki
The use of office tools as a primary agile management tool appears to be on the decline. The dedicated tools are better.
Office tools are really good for slicing, dicing and presenting data. Dedicated tools can be great and do many wonderful things, but there is always something they won't be able to do or won't do the way you want it, and for that you need the flexibility of an office tool suite. So the data import/export is an important feature of these tools.
While using Target Process as a primary management tool, I have used Excel or OpenOffice to record the Sprint Contract, allocate costs between two parallel projects, and do preliminary scheduling. The Wiki has been useful for storing information about the project which does not readily belong to a story, feature, release or sprint (although this is a very small amount of information).
When to use Dedicated Tools?
When you need to. ;-) The advantages of dedicated tools range from information reuse, handling multiple or geopgraphically far-flug teams. A customer of mine wants to have one tool and one process for coorindate work and information flow across 3 suppliers.
How to decide for yourself
Start with Michael's Agile Tools Decision Matrix. Think about the importance of the various criteria. Perhaps there are others which are important to you. But feel free to tweak the weightings and the scores to get a result that you like. (uh - the politically correct phrasing is 'get a result that applies to your situation').
What do I do? I start with cards for teaching Scrum. I like cards for the initial concept and planning workshops and for the sprint retrospectives. I also use cards to manage my own work (just me planning my work a scrum coach and trainer).
Beyond that, I like web based tools. Available everywhere, even on the train. Manage workflows, find information effectively, reuse information. The bigger the project (and the longer the product should live), the more important these advantages. I think these factors explain the growth in dedicated agile project management tools over the last 18 months.