As per the English Oxford Living Dictionary metrics is “A method of measuring something, or the results obtained from this”. And why do we need metrics? The answer of this question is to make the process predictable. Once we can predict the process, we can improve it.
Scrum.org introduced 4 basic key flow metrics in “The Kanban Guide for Scrum Team” named “Work in progress”, “Cycle time”, “Work item age” and “Throughput”. Teams may use or introduce new metrics if they needed, but at minimum these 4 metrics can provide a reflection of the current health of the overall process. With the help of these metrics, Scrum team can take appropriate action to improve their process and increase the value.
Work in Progress
The first thing to remember is that “Work in Progress” and “Work in Progress limit” are not the same thing. “Work in Progress limit” is a Scrum team policy they decided to put on individual phases. Different phases, usually represented in the form of columns on the Kanban board, and may have different “Work in Progress limit”. In typical situations, “Work in Progress” is less than or equal to “Work in Progress Limit”. Although in general reducing the “Work in Progress” increase the overall efficiency, but it is not guaranteed and not always be the case.
Calculating Work in Progress items are very easy and along with “Work Item Age” gives important informascrumtion about the process to discuss in the daily stand-up meeting. Since all the incomplete item put back to the Product backlog at the end of the Sprint, therefore this metric is not helpful in Sprint review. However, how many items are in progress can be used to improve the work process, because lower the number of “Work in Progress” items on average means we will have a potentially better workflow and on average reduce cycle time, therefore this metric is important in Sprint retrospective discussion. In fact, all the key flow metrics have some importance in Sprint Retrospective.
Cycle Time
“Cycle Time” is a lagging indicator. Lagging indicator, also called an output measure, can recorded after the event happened. Cycle time is the time elapsed between the items started and completed. In other words, we can say that cycle time is a time how long the work item is in “Work in Progress” state. If cycle time is high, then reducing “Work in Progress” potentially reduce cycle time.
This can be usually referring as “Lead time” or “Flow time”. Service Level Expectation (SLE), which forecast when an item will be completed probabilistically, is calculated from the Cycle time. However, if the project is new and there is no historical cycle time data is available, then it can be guessed.
One more important of cycle time is to get the feedback from the customer. “Cycle Time” gives us an idea how soon we can get a customer feedback. Increase cycle time reduces our customer interaction and feedback.
Sporadically team starts working on the items, which clicks the cycle time, and stop working on it due to any reason such as some external dependencies. In that case, although cycle time is keeping increasing, but, team is not working on that an item. If we need to find out such problem, then we can keep an information about when team is actively working on item and get a ratio on it with a cycle time to get the efficiency of the flow.
Work Item Age
“Work Item Age” is a time elapsed when item has started till now. In contrast to the cycle time, this is a leading indicator. It is calculated for only those items who is still in progress and not completed yet. Once the item is completed, then the cycle time metric comes into the picture. There is a possibility that an item may be in progress state for a long time, therefore it is also an important metric to discuss in the daily stand-up meeting to know if it can be improved. If there are some items not completed during the Sprint, then we can potentially use this metric in the Sprint planning meeting.
Throughput
“Velocity” is closest to the throughput and like velocity can be estimated the likely delivery date. It is the number of completed items per unit of time. In case of velocity, it is the number of completed story points per Sprint. However, unlike the velocity and user stories, throughput doesn’t distinguish between the size of the items, larger items and smaller items both have the same weight when calculating the throughput. If average cycle time decreases, then it potentially increases the average throughput of the process.
Throughput can tell us how fast team can complete the item and what will be the likely completion date. It also uses to estimate the capacity of the scrum team for the upcoming sprints therefore this is a very important metric in Sprint planning. Throughput can also be calculated on different phases of the process to acquire an idea of how fast items are entering and leaving different phases. Team can use more advanced techniques, such as Monti-Carlo simulation on throughput data to get more insight about the items.
