So, it’s no secret that one of the big benefits of ‘going agile’ is the ability/opportunity to track and optimise team performance.

The big question from a programme management and business perspective is:

How do you measure the operational costs/savings associated with improved efficiency or increased disruption within an Agile Software Development team?  

The answer – ‘easily’.

Here’s how:

1. Calculate the total weekly cost of your team (sum of all members of the Scrum team including employers costs)
2. Calculate the total cost per sprint
3. Calculate the total cost per velocity point for each sprint over time (cost per sprint/velocity point). Note the assumption will be that velocity increases over time thus reducing the cost per point over time.
4. Calculate the cost savings associated with the reduced cost per sprint i.e. how much would you have had to pay last sprint in order to achieve the current velocity?
5. Calculate the cumulative cost savings over time.

It’s important to note that although the vast majority of teams do take some time to achieve a stable velocity (3-4 sprints), some teams – particularly those that have worked together for a long time – gel so well together already that it’s hard to squeeze much more out of them.

The thing I like about tracking progress/change at this level is the fact that you’re offered a way to not only measure efficiency improvements over time but you can also measure the cost of disruption. For example, by introducing a new member of a team, the cost will increase but the velocity will take time to re-calibrate resulting in a temporarily inflated cost per point.

It is important to note that this will only measure the change in efficiency from the point that the Scrum Team ‘goes Agile’. It’s also worth noting that the velocity of a team will generally level off after about 3-4 sprints.   With that said, you could still use this method to measure the impact of sprint disruptions going forward – i.e. you’d notice a temporarily inflated cost per point.

If you want to measure the change from pre-scrum to post-Agile implementation then you could do one of two things:

1. Ask the team to retrospectively assign story point estimates to a ‘sprint-worth’ of work delivered pre-change e.g. if you’re now running two-week sprints, have the team estimate the work achieved in the two weeks prior to ‘going agile’. This can actually be used to help establish team velocity in the first place.
2. Use your judgement, team and stakeholder feedback to get a sense of the change. This will not provide a monetary value, but may be sufficient evidence to prove the point.

If you would like to save yourself the headache of building this template on your own, I’ve got one that you can download:

This Agile Management Template provides the following:

• Savings data in a table that can be used to analyse positive and negative variances***
• Plot cumulative savings on a graph to highlight trend over time

***(i.e. increased output vs. increased disruption resulting in reduced output).

The above data is generated automatically off the back of the following entry fields:

1. Employee name(s)
2. Employee annual salary(s) (including employee costs)
3. Sprint duration (weeks)
4. Velocity achieved each sprint

See inset for pictures of the results.  Let me know how you get on.

Good luck!

Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!

Related articles:

• Does Agile Programme Management Exist (agile101.net)
• Agile Programme Management Increases Flexibility (agile101.net)
• Introducing the Agile Epic Board (agile101.net)
• Agile Programme Management and Epic Boards (agile101.net)
• Lean, Scrum, Scrum of Scrums and Epic Boards (agile101.net)