I’m always surprised when I hear that a company or IT department is not using any metrics to measure how well their Agile teams are performing.
I can think of four things that are worth measuring right now – quality of build, quantity, precision (are you building the right things, for instance) and the effectiveness of your team.
As we know, one of the key principles of Agile is the drive for constant improvement, so measuring efficiency would surely fall under this point. And yes, while I agree that ‘working software is the primary measure of progress’ (as specified in the principles of the Agile Manifesto), is it so wrong to want to know that we’re creating the right things in the right ways?
I don’t think so. In fact, I tend to think that it can only help; any information learnt via these metrics can often feed right back into the Sprint Retrospectives.
Which Metrics to Use?
There are numerous metrics that you can use to identify the answers to the four points (and more) that I listed above. Before we talk about them in detail, let me say one thing: whatever metrics you do eventually choose, you should make sure that they benefit the team.
By that I mean that the information you receive via these metrics should be informative and give the team the evidence they need to make better decisions in the future. If the metrics don’t do that, they’re pretty pointless – just random data for the sake of it.
I’m not going to tell you which tools to use – that’s a decision you or the team has to make for yourselves – but let’s first talk about two readily accepted metrics that you should definitely see a benefit from.
In a nutshell, this is the amount of work a team can complete per Sprint. To get the velocity, divide the amount of work done by the time it took to complete it. This can be the total number of story points or the actual amount of man hours spent on a task. There are several different ways to establish velocity and you’ll need to find a way that works for your team.
At the very least, I recommend you measure velocity because it’s one way to allow you to make forecasts with confidence. Don’t forget that velocity will be affected by such things as holidays, sickness, new team members and more.
- Burndown Charts:
Burndown charts, although not mandated by the Scrum framework, are a common tool to measure and visualise progress. Simply put, they visually show the amount of work left to do in the remaining period of time.
The Development Team should be updating their work remaining daily and a Sprint burndown chart should be referred to regularly in order for this to be useful. This shows you visually where you are in the current Sprint and will allow you to change priorities (to drop lowest priority stories if you’re not going to meet your target, for instance, or add something from the Product Backlog if you are ahead of schedule) as needed.
Other potential metrics you could use include:
- Product Backlog – Are enough Product Backlog Items refined to ready and thus actionable in upcoming Sprints.
- Estimates v Actuals. – How effective is our planning?
- How much unplanned work was added to a Sprint.
- Iteration Cumulative Flow – some teams like to use an Iteration Cumulative Flow chart to visually view the state of work in the iteration, ie, whether it is defined, in progress, completed or accepted.
Whichever metric or metrics you decide to use, just remember to make sure it’s useful to the team as a whole; if it isn’t, you’re creating extra work for nothing and you should just walk on by. Using the right metrics, however, can help you to reach that Agile nirvana of constantly improving your processes.
The Kanban Master is Simon Kneafsey. Simon is an Accredited Kanban Trainer with the Lean Kanban University, the home of Kanban.
Simon offers Accredited Kanban training courses globally and works with clients to introduce Kanban to their organisations.
My Favourite Kanban Books2nd September 2016
Agile In A Day – Further Reading2nd September 2016
Agile in the mainstream2nd September 2016
Share this Post