anchor.diff:  In the screenshots below, you can see the average cycle time from BuildAndUnitTests to Production is 33m. When you drill down into each pipeline, you can see these details with wait times (shown in gray) ,and run times (shown in purple) towards production with each stage shown separately. From there, you can identify your slowest steps.
   
   <img src="/assets/images/blog/cd-metrics/average-cycle-time.png" alt="Continuous Delivery Metrics Part 3: Lead Time Diagram"/>
  +
   <img src="/assets/images/blog/cd-metrics/lead-time-workflow-analytics.png" alt="Continuous Delivery Metrics Part 3: Lead Time Diagram"/>
   
   This process can also be done manually, or with another tool. When you track the time and plot the different parts of the workflow, you can achieve similar results. The example below is a possible representation of the process, when done outside of GoCD. You can see there are some long-running parts of your pipeline (as in “Regression” here) and some long delays due to manual approvals.
   
   As you can see from our example, with lead time metric and the supporting details, you can identify your problematic steps: steps that are slow to complete and require lots of wait time will lead to overall low deployment frequency. From here, we recommend 
   
  -*focusing on the slowest steps first- that is what will give you the most gains. 
  -*converting manual approvals into automated ones, which will increase your level of confidence in the tests and automation. 
  -*Rewriting the tests in the slowest steps, if possible.
  +* focusing on the slowest steps first- that is what will give you the most gains. 
  +* converting manual approvals into automated ones, which will increase your level of confidence in the tests and automation. 
  +* Rewriting the tests in the slowest steps, if possible.
   
   Sometimes,  just focusing on optimizing a number of slow steps is not enough. Consider bigger changes to your pipelines. Start with drawing the value stream map and truly understanding the dependencies of your process. Identify opportunities to parallelize, rearrange your tests to start the slow-running tests earlier on in the process.
   
  -##Summary
  +##**Summary**
   
   In this post, we discussed what lead time is, why it is important, and how to act on long lead time. As we discussed in part 1, there are two other important metrics we recommend measuring: change fail percentage and MTTR. These metrics work closely with deployment frequency and lead time. We we will cover the interrelationship of these metrics in future posts.
  
positive.code: 
  In the diagram above, we calculate time from a commit (at the start of a CD pipeline) until when that code commit goes to production (at the end of the CD pipeline). Although other points in the CD pipeline have happened multiple times, it was only after three days that the deployment happened, so we calculate the lead time for that commit as three days.
  
  ##Why Lead Time is Important
  
  Lead time is a key element of lean theory. Focusing on reducing lead time will allow you to look at your process as a whole and understand the slowest parts. If teams and organizations only concentrated on lowering lead time they would improve and add more value to their organization. 
  
  
negative.code: 
  Finally, we recommend only considering the “delivery” part when calculating lead time for your CD process. If you define the start time from first line of code, and remove the “fuzzy front-end”, which include activities like requirement gathering, system analysis, prioritization etc, it is a simple and very practical metric to calculate.
  
  ##**An Example: How to Use Lead Time**
  
  We will continue with the hypothetical scenario we used in part 2 of the series, in this scenario, the development team received the complaint from their stakeholders that they didn’t get value very often. 
  
  