Metrics in Scrum and Kanban

    For various reasons, Scrum has become very widespread among IT companies. Many companies and individual teams began to implement Scrum in their projects. Some do it, others do not. A competent and experienced specialist before introducing something new always thinks about metrics. How to make sure Scrum implementation is going according to plan? Is team performance improving? Are there any problems? If you also asked these questions, welcome to cat.

    Cumulative flow diagram

    And here in Scrum there are very few answers. In addition to purely business metrics that can be used in almost any process ( ROI , Earned Business Value , Running Tested Features , etc.), Scrum also offers Velocity metrics . But already writtenit’s rewritten that you should not use Velocity as a metric . This can lead to unexpected unpleasant consequences.

    It turns out that there are no good metrics at first glance. At the end of the article, I will mention some implicit metrics in Scrum, but for now let's talk about the cause of the problems. The main reason is time. Business measures almost everything by time (even money is time). And in Scrum this very time is fixed (quickly we all remember the “iron triangle”) and the development is carried out by iterations. But inside the iteration, a lot of interesting things happen: we do tasks, user stories, test, collect the product, install, etc. And all this information is lost on the background of iteration. The so-called “noise smoothing” takes place.. If we dragged on with one activity, then we can catch up on another. After all, the iteration belongs entirely to the team and the team can “invent” anything inside the iteration, if only everything is ready at the end. This approach is very good for planning, but disgusting for metrics.

    Firstly, we are very rarely able to take metrics - at the end of the iteration. And this is at best once a week. Basically, all the same every two weeks. Secondly, we already mentioned “smoothing” and it also makes its own adjustments. The whole iteration, the situation was very bad, but in the end everyone made an inhuman effort and voila - everything is ready and the metrics are in order. Is it good or not? Not! We lose useful information and do not learn from our mistakes.

    Things are completely different in Kanban. Here, attention is paid to each task.. Metrics are removed from the entire task flow that passes through the development team. Here is a short list of metrics:

    • Cycle Time - the time that the task was in development from the moment when it was started to be worked out until the moment when it went through the final delivery phase.
    • WIP - the number of tasks simultaneously in work. It is divided into different stages of work on the task.
    • Lead Time - the time from the appearance of the task to its final delivery. Includes Cycle Time and latency in the implementation queue.
    • Wasted Time - the time that the task spends in different queues, and not directly in the work.
    • Effectiveness is the percentage of time that is spent directly on working with a task, rather than on expectations in various queues.
    • Throughput - the number of tasks a team can perform per unit of time (day, week, month).


    This simple list of metrics allows you to fully understand and control the development process, constantly analyzing and improving it. Ideally, these metrics are considered in the context of the categories of tasks (by size, type, urgency) in order to further improve understanding of what is happening and allow more accurate prediction of team work results.

    I promised to mention implicit metrics in Scrum. These metrics can be collected using the Burndown Chart. You can analyze it in order to determine the patterns of team work, considering the daily progress and smoothness of the schedule. You can strengthen the analysis. To do this, you need to categorize tasks and build a Burndown Chart for each category. Some teams track task metrics within an iteration, but in my opinion this is somewhat contrary to the principles of Scrum - within an iteration, a team can work on tasks in an arbitrary order.

    To summarize. Kanban metrics are much stronger than Scrum, but this does not make Kanban an easier to implement approach. On the contrary, Kanban requires a lot more responsibility, control and analysis from the team with continuous improvement. But from the point of view of business, Kanban is much more transparent and controlled.

    What metrics do you use? What metrics worked well for you in Scrum?

    Also popular now: