Predicting Program Health – Insights into Leading and Lagging Indicators

URL copied!

Categories: AgileTechnology

As human beings, we want to understand what the future holds for us. We make decisions based on the information available to ensure all risks are either resolved or mitigated. Often, these decisions are based on analysis done on historical data.

Consider this: I plan to run a marathon two months from now. I have never run a marathon – just a couple of 10Ks. I need a plan to prepare myself.

What is the data available to me right now to make this plan? It comes from the preparations I did for my 10K. I did not start running 10K on my first day; I started with 2K. After 10 Days, I was able to take it up a notch to 4K, and a week after that to 5K. It took me a month and a half to practice for my first 10K.

Weather also played a part in my runs. On a humid morning, I could not do a 5K so easily. Cool nights were better. But to make a long story short, I had enough data from my past experiences to begin preparations for the marathon.

Now that I have the data, can I predict my success or failure for the marathon? I still have to create key milestones and KPIs by which to measure my performance. If the marathon is in two months, I should be able to hit 10K in the first three weeks.

Am I in shape to start running 5K to start with? What about the weather? How about where I plan to train? Also, do I have enough time in my schedule to plan for my training?

Similar questions arise in the lifecycle of the products we are building. Leadership – both at the team and program level – need data and information to help remove impediments and bring predictability. These can be driven by two different kinds of indicators: leading and lagging.

Leading Indicators

Leading indicators focus on the inputs going into building a product. These help determine whether we have the right ingredients in place to build the right product in a timely manner.

Leading indicators are hard to measure and a lot of times depend on historical data available at a point in time. In the story above, the leading indicators for me to run a marathon successfully are: How much time will I be putting in everyday to train for the run?

For example, if I say two hours, I can track that on a daily basis and see if I am doing that because if not, I will surely miss my target. In product development, the health of a backlog is a good indicator of where my teams are heading before the start of a sprint or PI. Some other leading indicators can be:

Release Burndown used to track our progress for a release. This will help programs make the right decisions.
Backlog Readiness, as the health of our backlog is a key leading indicator of how our Sprints and PI will go.
Epic Readiness.
Story Readiness.
Capacity v/s Load. Do we have enough work to feed our teams and/or trains?
Stable Velocity. Based on historical data, will our teams be able to achieve the commitments they are making?

Lagging Indicators

Lagging indicators focus on the outcome. They are easy to measure and help develop a pattern of how teams and programs are doing. Leaders can gain insight from this data, do root cause analysis, and find where the bottlenecks might be or what areas to improve.

In my story above, after two weeks of training, reviewing my performance data gave me insight into how well prepared my body was for the run. Based on that insight, I made changes to my routines to ensure I would improve on them in the next two weeks. Lagging indicators can be:

UAT/Production Defects Density, the quality of the code deployed in Production/Higher controlled environments.
The number of unplanned Production Releases. How often are we deploying code in production? RCA will lead to key areas to fix.
Sprint/PI Spillovers (Committed v/s Completed), or the team’s ability to meet the commitments.
Sprint Churn. How stable are our backlogs during the Sprints?

These examples of leading and lagging indicators vary from program to program and based on the point in time or milestone for which you are developing these reports. They can also be different for various leadership groups and the structural hierarchy from which you are looking at product development.

Ultimately, you want your program to define leading and lagging indicators for tracking its health. And last but not least, the data used for building these metrics should come from a single source of truth.

Have you defined your leading and lagging Indicators yet?