Which Agile tool should you use?

After browsing through discussions on the Agile Alliance LinkedIn group this morning I came across a thread: Best SCRUM tools in the market. I posted a comment on this thread and thought it worthwhile expanding on this and sharing details of my analysis.

A while ago I did some detailed research into agile tools for managing distributed Scrum teams. There were 9 tools that I looked at in total evaluating each based on the following metrics: functionality, price, usability and scalability. For each of the tools I either created a test account or downloaded and installed a test version of the application. The top 3 tools that I came up with were : Target Process, Rally and JIRA with Greenhopper. Here is a detailed matrix containing my analysis:

* ping me your email address if you interested in the cost breakdown per user details and I will send through the full spreadsheet – andrew [at] thekeggies [dot] com:

full view

We decided to go with JIRA with Greenhopper and have been using it with our distributed teams for a couple years now…to good effect! It is an extremely affordable solution and does more than is necessary to enable teams to get things done. I have found that the Atlassian Greenhopper team listen closely to what their users are saying and have an aggressive approach product improvement and development which is encouraging. Here is some evidence.

Now don’t just dive into using an automated tool if you are just starting out with Scrum or any other Agile approach. If you have a collocated team, start off using a white board and stickies and automate once you are comfortable.

KPI’s for Agile and Scrum teams

Over the past week I have been taking some time out to research effective metrics/KPI’s and processes for measuring and tracking the performance of Scrum teams.

There are many suggested metrics all with varying degrees of complexity in terms of data tracking and calculation. My goal was to find team metrics that were easy to track and calculate – see below:

Team Performance

• Velocity – story points completed
• Goals achieved (yes/no)
• Product owner satisfied (yes/no)

“Velocity” is the most popular metric employed by Agile teams. It doesn’t always provide you with scientific accuracy but is a good indicator of progress made. The story point estimation of the product backlog upfront is a time consuming process, but worthwhile in the long run for both the team and business to provide a clear indication of capacity and delivery.

“Goals achieved” and “Product owner satisfied” are two simple metrics which both give a clear indication of the team’s delivery. Tracking the product owner’s specific comments and feedback each sprint creates a transparent testimonial of the team progress over time – very handy.

Measuring individual team member’s performance is a little more complicated. It is generally accepted that metrics alone do not reflect a team member’s (developer/tester/analyst…) performance accurately and I tend to agree. A combination of metrics and peer review feedback; however, provide a far clearer picture. I selected a couple below:

Individual Team Members Performance

• Hours Estimated vs Actual
• % Contribution
• Peer review feedback using 360 degree review tool

I like to think that the Hours Estimated vs Actual metric indicates the following:

1. Competency and understanding of the architecture and technology stack
2. Understanding of business requirements and scope
3. Confidence in their own, and the team’s, ability

This; however, is fairly subjective – I would suggest writing up your own indicators for this metric and discussing it with your team members before agreeing.

% Contribution is a metric that brings back memories of working on group projects at university. Being aware that one is being measured based on % contribution is a sure fire way to encourage team involvement and buy in. The senior members of your team are usually in the best position to gauge the contribution of team members but I would suggest taking this one step further and incorporating this metric into the peer review process as feedback based on perceived contribution provides some interesting insight into team dynamics.

There are plenty of 360 review tools out on the web. After much scouting around I settled on two options: Survey Monkey and Dynamic Forms using Google Docs.

Google Docs is the best option as it is 100% free and allows great flexibility. You can read more about the 360 degree survey I set up using Google Docs by clicking on this link:

Survey Monkey gives you a free account and ability to create and run a survey but limited capacity to download and analyse the data.

I have created a survey here which I am planning to use at the end of this quarter – this is a work in progress so let me know what you think?

Click here to take survey

Now the proof is always in the pudding – I will post some feedback on our progress with tracking team and individual members’ performance this quarter utilising all the above options and let you know how it goes. Ciao for now.

360 Degree survey using Google Docs

I have recently been working on sourcing tools for conducting 360 degree peer reviews for my development team and department. The mandate was to find a tool (a) that is free (b) that allows easy manipulation of results for interpretation. As you can imagine this is not an easy mandate to fulfil with loads of paid-for solutions on the market.

I managed to discover 2 alternatives – Survey Monkey and dynamic forms using Google Docs. Google Docs wins hands down as the solution is entirely free and the results available in spreadsheet format for download and manipulation. Definite winner!

Here is an example of a 360 degree survey that I set up – let me know what you think.

360 Survey excel source file