Cycle Time & Lead Time @ Scrum

> I have been discussing with other Scrum
> Masters and line managers at our
> organisation whether or not LEad Time and
> Cycle time can and should be used while working with Scrum.

The answer is that they can and *might* be used in Scrum. However, the key measure that Scrum Teams should care about is whether or not sufficient value is being delivered to the PO.

Cycle time and lead time are secondary measures which can potentially help a team improve the value delivered. For example, a team might use these metrics to help find efficiencies and increase throughput.

Only the Scrum Team itself can determine whether or not certain metrics should be used as part of their process. They would typically address this matter during a Sprint Retrospective.

+1 to Ian's response.

Start measuring value instead of Lead/Cycle time: http://ebmgt.org

Why not doing both, that's my question?



Cycle time is a great indicator of team performance and can be used also for analyzing team process and finding where are the issues in the flow. Also, it should be used to see if the team's flow is stable or not. 



I absolutely agree with Ian and the team should be focused on delivering value to the customer, but why not using the Kanban practices to help you get the team more focused and process more productive.

As @Ian Mitchell points out the important thing is to measure value produced.

Lead and Cycle Time will help a team become more efficient while adding some predictability to their ability to deliver which can aid the Scrum Team's capability to provide delivery estimates.  But even a team that can predict delivery dates exactly may not be delivering anything of value.  

So can Lead and Cycle Time be used in Scrum?  Yes. Should it be used? That is up to the team to decide. Do I advocate teams to use them?  Yes but only for their own benefit and mostly when I see a team struggling to achieve a consistent cadence of delivery.

In Manufacturing, you are building the same product/component over and over following the same consistent processes.  So, you can see how cycle time is an accurate and consistent measurement for predictability. 

But in Scrum, each story and task are of different sizes and complexity (and may follow different processes) so you would expect that their cycle times between states would be vary significantly based on the mix of Stories.  How do you use Cycle time confidently for predictability with so much variation between stories? 

so you would expect that their cycle times between states would be vary significantly based on the mix of Stories.

Yes

How do you use Cycle time confidently for predictability with so much variation between stories?

Just like you would use story points to measure velocity. Using means/averages.  It is also how manufacturing will utilize those metrics.  They can measure cycle time to measure the production of a class of items just as they can specific items. However, as the people doing the work become more familiar with the work or unexperienced people are introduced into the work, those same activities will fluctuate in time.  As you point out, in software you would not want to measure specific items because you will never do the same work without knowledge gained from previous work. 

You might want to read these books by Daniel S. Vacanti.  He goes into how these metrics can be used effectively and even provides additional insights to other metrics.  Read them in the order I list.

Actionable Agile Metrics for Predictability

When Will It Be Done?