Agile Tool Selection

Posted on October 17, 2011

The question of which agile tool a team should use comes up again and again.   For some reason this always seems to generate a fair amount of debate, research, analysis and hand wringing that most projects could simply do without.  Perhaps any debate about tools on an agile project is a little suspect, given that the first agile value on the agile manifesto ( is:  Individuals and interactions over processes and tools.  But there is the practical need to having some system in place to ‘manage’ the work – particularly with a distributed team – that good tool can support and be of great value to the team.

My preference for an agile project is to start out as simple as possible – hand written story cards pinned to a cork board with yellow post it notes for the task break down.  To calculate metrics (velocity is really the only one that I care about early on) and generating the Release Burndown (or Burn Up) charts and the sprint burndown chart can easily be done with some daily data entered into a spreadsheet.  (It may take 5 minutes a day to enter this data after the standup meeting – at most.)  This keeps it simple, easy, and focuses the team on getting stuff done – not creating metrics for the project.

The only drawback to a physical taskboard is that it really works best with a co-located team.  I always suggest that you start with a dedicated, co-located team when starting an agile project, but it is not always possible to do so.  (You can, of course,  “do agile” with a distributed team – it just requires different support.)

When working with a distributed team – it can be very helpful to add some web-based tool support to the project to make it easier to manage the backlog, view who is doing what, and capture daily status data needed to create the sprint burn-down chart(s).  So, what tool do we select for this support?

Selecting a Tool

The short answer: Find something that works for the team, but don’t spend a lot of time doing it.

What works well for one team, may not for another – but in my experience, there are a few things that teams typically want from an agile tool.  I have listed these in the table below and indicated their relative importance:

Using these as the key features for selecting a tool, I have compared some of the market leading tools in the matrix below:

Looking at the feature set and the products in the market, you can see that many of the products are competitive with one another on a feature by feature basis.  It really comes down to deciding how much you want to spend and which UI (UX) you find the most comfortable.

I usually suggest making things simple and going with a Market leader like RallyDev or VersionOne and be done with it.

Again – find what works for your team, but don’t spend a lot of time on it.  Focus on getting the work started and getting something done!

 Enough Already!

I found this site with a list of current agile tools:  This goes well beyond the subset that I put my comparison matrix above.  There are just too many tools out there all doing pretty much the same thing.  I get back to my original point – for most teams I am not sure it matters which tool you select.  If the tool supports your team in a low-friction way – and it works for you and your stake holders – buy it, and get started on doing the work.