metrics

Collecting metrics for no reason

I’ve worked in many places where an edict has come down from senior management to start collecting metrics, without any direction. While usually well intentioned, these requests are frequently poorly considered and poorly implemented. Many times I’ve asked “what decisions are going to be made from these” and nobody knows.

Gaming metrics

When I suggest that people will game whatever metrics we put in place, I’m often met with shocked indignation. We would never game the numbers! And yet we do.

Prioritization

There two different times that we need to prioritize work and we should be using completely different approaches to that prioritization, for each stage.

Wait states

The metrics covered in our Flow Metrics Basics class show how to measure different aspects of flow, but those metrics don’t in themselves, show how to improve the flow. We’ll look at one way to improve now.

Basic Flow Metrics

Flow metrics tell us about the activity in the system; how well is the work flowing. These are often the first metrics that I consider when trying to improve a system. I start here partially because these metrics are easier to collect than many others, and because I can still make many effective decisions based on just this.

Visualizing Flow Efficiency

I’m playing around with visualizing flow efficiency in my JiraMetrics tool. Flow efficiency is the percentage of time that we’re actually adding value to the work item divided by the total time. So if a ticket is open for 10 hours but in that time we only spend 2 hours actually working on it then the flow efficiency would be 2 / 10 or 20%.

Tracking metrics

Most companies I work with have a desire to track metrics for their development teams, and I support this. It’s hard to improve something we can’t see so metrics are a good first step as we seek to improve.

Flow Efficiency

Flow efficiency (sometimes called Cycle Efficiency) is a metric that gives us a sense of how much time work is waiting. A flow efficiency of 100% would indicate that we are adding value to the work item for the entire time it’s in progress. 50% would imply that half the time we’re working on it and half the time the work is just waiting.

Who should look at what metrics?

When we talk about metrics, there is often an assumption that everyone in the company needs the same data to make decisions and this is dangerously incorrect. Different levels of the organization need different kinds of data to make effective decisions. Yet, all too often we use the wrong data at the wrong point.

Technical Debt

The term “technical debt” is widely used in the industry even if there isn’t a clear definition of it and almost nobody uses the term in the way Ward Cunningham meant when he first coined it. It’s most commonly used to describe things in our environment, usually but not always code, that slow us down. These are things that are working - not bugs - but that are implemented in a poor way that makes them more difficult to understand or modify.

One Thing vs Multiple Things

When creating a forecast first ask yourself whether you are forecasting One Thing or Multiple Things. It’s not always clear which of these situations you are in but the approach you take to creating the forecast will differ significantly. This post will help you to figure out which approach to take.

Improving Predictability - Average Age

In a previous post I’ve introduced the four assumptions behind Little’s Law and discussed the first two assumptions in detail. If you haven’t read those previous posts I encourage you to go back to understand the background. As a reminder, the four assumptions are listed below.

Improving Predictability - All work must finish

In a previous post I introduced the four assumptions behind Little’s Law and the idea that they are critical to understanding and improving your system’s predictability. We’ve also already discussed the first assumption regarding the equality of average arrival and departure rates. If you haven’t read those previous posts I encourage you to go back to understand the background. As a reminder, the four assumptions are listed below.

Improving Predictability - Average Arrival and Departure Rates

In a previous post I introduced the four assumptions behind Little’s Law and the idea that they are critical to understanding and improving your system’s predictability. If you haven’t read that post I encourage you to go back to understand the background. As a reminder, the four assumptions are listed below.

Improving Predictability

Little’s Law is an equation that frequently appears in discussions of Kanban systems. While initially formulated as a part of queuing theory to describe the length of time people would spend in stores it has since been applied to many other contexts from manufacturing to knowledge work (particularly Kanban for the purposes of today’s conversation).

Determining cycle time from an online system

This post is aimed at a fairly niche audience so if you aren’t trying to make sense of poor data out of some ticketing system then you might want to skip this one.

Improve the work, not the metrics

One of the key practices supporting continuous improvement is making your work, and how you do the work, visible. This starts by tracking the progress of that work in a highly visual way, often by using a kanban board. Once that work is being tracked we can begin to gather that data and start to gain insights into where our biggest opportunities for improvement are, often by using the metrics defined in The Three Flow Metrics (Plus One).

The three flow metrics (plus one)

Some of the best indicators of team performance are the flow of both new information into the team and of value out of the team. If we can improve visibility into these indicators, and therefore the opportunities for the team to improve the way they work, it becomes possible for the team to support their organization in ways they couldn’t before. There are three standard metrics that are core to understanding the effectiveness of any flow-based system. The relationship between the three metrics is defined by Little’s Law. When applied to the systems used to enable knowledge work the law is usually restated in terms of Throughput, Work In Progress (WIP), and Cycle Time.