How to measure Lead Time based on your Continuous Integration Strategy
How to measure Lead Time based on your Continuous Integration Strategy
A 4 Key Metrics Article Series
What is Lead Time?
Lead time is the time it takes to go from a customer making a request to the request being satisfied.
We can translate the previous sentence as the time of a card that takes move from Ready to Start to Done in a Scrum or Kanban board.
An important aspect is the Definition of Done, which implies that the user story is in production and it’s being used by the customers.
Some people interpret “from a customer making a request” when a customer or a stakeholder request some feature. I disagree.
The reason is that we cannot take for granted what people request to us without a proper discovery phase. That’s because I start counting as “from a customer making a request” when the Product Owner shares a well-defined user story. So, the Product Owner might have their own Backlog ready, but until it’s not moved into Ready to Start, the Lead Time didn’t start yet.
I consider the Product Owner as a Proxy or representative of Customer Requests.
An example of Problem Discovery vs Product Development is if we are using a framework as Double Diamond, I would consider the request as being made somewhere in the Problem-Definition point in the middle.
Continuous Integration Strategies
The Continuous Integration Strategy you’re using will mark how you can track the Lead Time.
Regardless of your branching strategy, if it’s GitFlow or another, it doesn’t affect how to measure Lead Time since it only takes into account production BUT it affects the Lead Time metric on how fast you can be.
Continuous Delivery Pipelines
In Continuous Delivery Pipelines, the main characteristic is that there is a human involved to promote a new version to production.
Continuous Deployment Pipelines
On the other hand, in Continuous Deployment Pipelines, there is NO human involved. When a developer commits to the main branch, all the changes are propagated through all environments reaching the Production Environment.
This is the most advanced Strategy I know to date.
Techniques to Decouple Deployments of Delivering Code - Feature Toggles
Feature Toggles (aka Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code.
There are multiple ways to use Feature Toggles, the way that it helps on Lead Time is the Release Toggle. They cover the need of: "separating [feature] release from [code] deployment."
These are feature flags used to enable trunk-based development for teams practicing Continuous Delivery. They allow in-progress features to be checked into a shared integration branch (e.g. master or trunk) while still allowing that branch to be deployed to production at any time. Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
See more in Feature Toggles - Martin Fowler Article.
Combining Continuous Integration Strategies with Ways of Working
Continuous Delivery with Feature Branches and Pull Requests
We are using a Continuous Delivery Pipeline and Feature Branches plus Pull Request to merge finished features.
Lead Time = Time of Deploy Production Pipeline Step finished - Time the User Story was added to Ready to Start
Tools you can use for tracking Lead Time
Ticket System like Jira or Trello
Continuous Integration Solution like Circle CI, Jenkins, or GitHub Actions
The reason you can use the CI System is because your release strategy is coupled to the branching strategy and deployment system.
Continuous Delivery or Deployment with Feature Toggles
Using Feature Flags helps us to decouple Code Deployment from Releasing a Feature.
Lead Time = Time of Feature Toggle Enabled - Time the User Story was added to Ready to Start
Tools you can use for tracking Lead Time
In this situation, you cannot use your CI System because your release strategy is decoupled from deploying code.
Meme for you
