Metrics in Scrum and Kanban
For various reasons, Scrum has become very widespread among IT companies. Many companies and individual teams have begun to implement Scrum in their projects. Some get it, others not. A competent and experienced specialist always thinks about metrics before introducing something new. How to make sure that the introduction of Scrum goes according to plan? Is team performance improving? Are there any problems? If you also asked these questions, welcome under cat.
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 suggests the Velocity metric. But it’s already written that it’s not worth using Velocity as a metric. This can lead to unexpected unpleasant consequences.
')
It turns out that at first glance there are no good metrics. 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 practically measures everything by time (even money is time). And in Scrum this time is fixed (we all remember the “iron triangle” quickly) and the development is carried out by iterations. But inside the iteration, a lot of interesting things happen: we do tasks, user stories, test, build a product, install, etc. And all this information is lost on the background of the iteration. There is a so-called "noise smoothing" . If we delayed with one activity, we can catch up with another. After all, the iteration belongs entirely to the team and the team can “invent” anything within the iteration, if only everything was ready at the end. This approach is very good for planning, but disgusting for metrics.
First, we can rarely take metrics at the end of an iteration. And this is, at best, once a week. Basically, all the same every two weeks. Secondly, we have already mentioned “smoothing” and it also makes its own adjustments. Throughout the iteration, the situation was very bad, and in the end everything did an inhuman effort and voila - everything is ready and the metrics are in order. Is this good or not? Not! We lose useful information and do not learn from our mistakes.
Quite different things are 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:
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 terms of task categories (by size, by type, by urgency) in order to further improve the understanding of what is happening and allow a more accurate prediction of the team’s results.
I promised to mention implicit metrics in Scrum. These metrics can be collected using the Burndown Chart. You can analyze it to determine team work patterns, reviewing daily progress and smooth graphics. You can enhance the analysis. To do this, you need to enter a categorization of 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, the team can work on tasks in a random order.
I will sum up. In Kanban, metrics are much stronger than in Scrum, but this does not make Kanban an easier-to-implement approach. On the contrary, Kanban requires much more responsibility from the team, control and analysis with continuous improvement. But in terms of business, Kanban is much more transparent and controllable.
What metrics do you use? What metrics worked well for you in Scrum?
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 suggests the Velocity metric. But it’s already written that it’s not worth using Velocity as a metric. This can lead to unexpected unpleasant consequences.
')
It turns out that at first glance there are no good metrics. 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 practically measures everything by time (even money is time). And in Scrum this time is fixed (we all remember the “iron triangle” quickly) and the development is carried out by iterations. But inside the iteration, a lot of interesting things happen: we do tasks, user stories, test, build a product, install, etc. And all this information is lost on the background of the iteration. There is a so-called "noise smoothing" . If we delayed with one activity, we can catch up with another. After all, the iteration belongs entirely to the team and the team can “invent” anything within the iteration, if only everything was ready at the end. This approach is very good for planning, but disgusting for metrics.
First, we can rarely take metrics at the end of an iteration. And this is, at best, once a week. Basically, all the same every two weeks. Secondly, we have already mentioned “smoothing” and it also makes its own adjustments. Throughout the iteration, the situation was very bad, and in the end everything did an inhuman effort and voila - everything is ready and the metrics are in order. Is this good or not? Not! We lose useful information and do not learn from our mistakes.
Quite different things are 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 she started to engage, until the moment when she passed the final delivery phase.
- WIP - the number of tasks simultaneously in the 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 Queuing Time for Implementation.
- Wasted Time - the time that the task spends in different queues, and not directly in work.
- Effectiveness is the percentage of time that is spent directly on working with a task, and not on waiting in various queues.
- Throughput - the number of tasks that a command 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 terms of task categories (by size, by type, by urgency) in order to further improve the understanding of what is happening and allow a more accurate prediction of the team’s results.
I promised to mention implicit metrics in Scrum. These metrics can be collected using the Burndown Chart. You can analyze it to determine team work patterns, reviewing daily progress and smooth graphics. You can enhance the analysis. To do this, you need to enter a categorization of 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, the team can work on tasks in a random order.
I will sum up. In Kanban, metrics are much stronger than in Scrum, but this does not make Kanban an easier-to-implement approach. On the contrary, Kanban requires much more responsibility from the team, control and analysis with continuous improvement. But in terms of business, Kanban is much more transparent and controllable.
What metrics do you use? What metrics worked well for you in Scrum?
Source: https://habr.com/ru/post/173565/
All Articles