Lord Kelvin once said "if you cannot measure it, you cannot improve it". When it comes to agile, measurement should be the bread and butter of your everyday workflow. But what should we measure anyway? Let's find out together.
Whether you’ve decided to use Scrum or Kanban, or even a mix of both, the goal is always the same: to optimize your delivery time while keeping track of your software team. And to do so, you need the appropriate metrics. However, with so much information produced from your project board, choosing the best metrics can be a handful. The question here is what is actually best for your project. Today, we are going to review different metrics and/or charts and discuss how they can help understand your team and optimize the development of your project. Let's get started:
Sometimes simplicity is king, and this is the case for the work time breakdown chart. Want to find out what is the current state of your Kanban board (or Scrum sprint)? Just put your tasks in a pie chart along with their state (column). Doing so can help you easily see what happens right now, what is the state of the sprint and how much work has to be done.
Though originally a Kanban-oriented metric, there is no reason why you cannot use a cumulative flow diagram in any agile board. The goal is simple: view the progress of your project at a glance and identify bottlenecks. The diagram shows the distribution of tasks in the different columns over a period of time. So, for instance, if you see a sudden rise in the Accepted/Done column, this means that your team has started delivering things faster! If, on the other hand, the Work In Progress seems to get out of hand, you may have to take immediate action, as this means that you have a development bottleneck. This can be due to a growing number of tasks, due to unseen interconnections between them or even due to weak estimation of points.
The cycle/lead time is the time required for a task to go from one state/column of your board to another. More formally, the cycle time can be defined as the time required to complete tasks that are in progress, while the lead time measures the time for your whole process (from idea/backlog to completion). This is also a very popular metric, especially for Kanban boards, as it allows you to measure the throughput of your team (via cycle time) and of course identify bottlenecks. Most importantly, however, the lead time shows your responsiveness to stakeholder demands; keeping it short means faster feature completion.
Two metrics that are quite similar to each other are throughput and velocity. Throughput is a Kanban metric that measures the number of tasks processed during a unit of time. As such, in a Kanban model, you typically measure the number of tasks processed per week and can easily find out whether you are consistent. Velocity is similar in its computation as it measures the number of points per sprint. Assuming for example a biweekly sprint, velocity can be computed by measuring the number of points delivered during the sprint. Note that if you use Scrum, you have to take care to find your velocity and stick to it. Any deviation from the estimated velocity (or throughput) usually means a bad estimate.
Let me state this again with a word of caution: you cannot force a software team to constantly increase their velocity – this is like asking a basketball player to score ten more points in each consecutive game. What you have to do is find your team’s comfortable throughput in order to produce good estimates and make sure that delivery is always on time. In this sense, the perfect velocity/throughput diagram is actually a straight horizontal line relevant to your workforce.
I’m going to close with this - too cliché - quote: “if you cannot measure it, you cannot improve it”. The quote is by Lord Kelvin, who, roughly two centuries ago, had already identified the potential that comes with measuring your work. When it comes to agile, measurement should be the bread and butter of your everyday workflow. Choosing what to measure is only the first step, which (hopefully) I managed to outline in this post. Actually measuring and using it to your advantage is of course another story.
Till next time folks!
This post has been published on www.productschool.com communities.