This article covers some common questions on the purpose of Lead Time and Cycle Time measurements in software development.
Lead Time and Cycle Time means different things to different people, depending on when the clock starts, team purpose and industry, so let’s be specific on what states or steps can be measured, with the Definition of Done being consistent across the following.
- Business Initiative / Customer Engagement to Done
- Story Creation to Done
- Story Readiness to Done
- In Progress / In Development to Done
Customers care about lead and cycle times, so surely development teams should care too?
In software development, as opposed to software maintenance or inventory orders, it is not recommended to use average lead or cycle times to make customer commitments or manage expectations on specific work.
In software maintenance, service level agreements (SLAs) can be in place and response time SLAs are generally more favoured by service providers than resolution time SLAs.
In software development, which is more exploratory and less understood than software maintenance, lead times are less applicable, as customers are more focused on product or feature delivery dates. Any dates provided are usually based on specific analysis, as the amount of work, complexity and risks will vary for each feature in software development.
In software development, customers care about collaboration to develop the best product or feature. In Agile software development, customer collaboration is a core value and customers are part of the team. Regular customer feedback is needed to inspect and adapt the product during development, at regular intervals. These regular review points and the input needed from the customer should be communicated upfront and throughout development.
So, if customers developing a product care more about delivery dates and regular engagement, what problems are lead and cycle times trying to solve?
Teams want to manage their development workflow to optimise work items moving from In Progress to Done. Once the workflow is visualised, one way to measure optimisation is to measure the cycle or In Progress to Done Time.
Why visualise the workflow?
The workflow is visualised so that everyone can clearly see all states where bottlenecks can be easily identified and managed to reduce load and overburden to improve flow.
How do you optimise the workflow?
The first way is to remove waste, often caused by overloading, overburden and task switching. Limiting work in progress (WIP) helps with this by maintaining momentum on one story at a time, per person or per pair. Waste is secondly reduced by automating and standardising tedious, repeatable processes or any process that is prone to human error.
Other than overloading, what are the usual impediments to optimising flow?
Stories not meeting the Definition of Ready, dependencies outside the team and only one person being able to complete a story being absent. Refining stories to meet an explicit Definition of Ready should identify most impediments to completing a story. Pair programming and knowledge sharing within the team will mitigate absences.
For each story, does the whole team understand the amount of work, complexity of work and risk in doing the work? Can this understanding be grouped into sizes?
To achieve this, the whole team needs to discuss and refine stories together, usually in Product Backlog Refinement or Grooming sessions.
To accurately measure Cycle Time over weeks and months, should work items or stories be the same size?
Ideally, yes, to achieve a more accurate measurement, but significant effort to split or merge stories to be roughly equal in size is considered waste.
If work cannot be the same size, can the average Cycle Time for ‘small’, ‘medium’ and ‘large’ stories be compared?
The prerequisite to this is 1) sizing stories and 2) a tool that accurately measures Cycle Time for each story size.
Why does story size matter?
Stories of different amounts of work, complexity and risk will have different Cycle Times. If stories are not consistent in size, the size of stories completed over a particular period should be included in the Cycle Time narrative.
How does Cycle Time differ when you count non-working days?
In reality, all stories may span a weekend, followed by some stories spanning a weekend, followed by no stories spanning a weekend and then again in a random order. Crudely speaking:
- If 6 team members pair on 3 equally sized stories on Monday AM and complete Wednesday PM, the average In Progress to Done Time will be 3 days;
- If 6 team members pair on 3 equally sized stories on Thursday AM and complete Monday PM, the average In Progress to Done Time will be 3 days not counting weekends and 5 days counting weekends.
Surely, considering weekends and public holidays is the same as considering meetings, hackathons, sickness, etc.?
Meetings and other work events are part of the focus factor % and team allocation %, which can be increased through mitigations e.g. less meetings, more automation, etc. Weekends and public holidays cannot be mitigated and have a bigger overall time impact than anything else. Absences through annual leave and sickness can be mitigated through pair programming and knowledge sharing within the team.
Surely counting all non-working days can be averaged out over time, so it doesn’t matter?
It depends on the audience. It matters to individual teams making small adjustments to optimise their workflow and wanting to measure these small improvements. Counting non-working days can obscure visibility of these marginal, incremental improvements.
What are your thoughts and how do you use Lead Time and Cycle Time? How do you immediately see marginal, incremental improvements in Cycle Time if your work items differ in size and span random weekends?