Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
PaulDuvall authored Nov 17, 2017
1 parent b3ab6fc commit 45cc425
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ The list of pipelines in the dashboard cannot be generated dyanmically so anothe
| `Lead Time` | How long it takes for a change to go to production. | The mean amount of time from commit to production, including rework. | This is the number the business cares about most, as it represents how long it takes for a feature to get into the hands of the customer. If this number is too large, look at improving the availability of the pipeline `(MTBF / MTBF + MTTR)`. |
| `MTBF` | How often does the pipeline fail. | The mean interval of time between the start of a successful pipeline execution and the start of a failed pipeline execution.| This number should be high in comparison to `MTTR`. If this number is low, then consider improving the reliability of the pipeline by first researching if the root cause is the quality of new code being committed, or the repeatability of the infrastructure and test automation. |
| `MTTR` | How long does it take to fix the pipeline. | The mean interval of time between the start of a failed pipeline execution and the start of a successful pipeline execution.| This number should be low as it is a measure of a team's ability to "stop the line" when a build fails and swarm on resolving it. If the `Feedback Time` is high, then consider addressing that, otherwise the issue is with the team's responsiveness to failures.|
| `Feadback Time` | How quick can we identify failures. | The mean amount of time from commit to failure of a pipeline execution. | This number should be low as it affect `MTTR`. Ideally, failures would be detected as quick as possible in the pipeline, rather than finding them farther along in the pipeline. |
| `Feedback Time` | How quick can we identify failures. | The mean amount of time from commit to failure of a pipeline execution. | This number should be low as it affect `MTTR`. Ideally, failures would be detected as quick as possible in the pipeline, rather than finding them farther along in the pipeline. |

## Cycle Time vs. Lead Time
`Cycle Time` and `Lead Time` are frequently confused. For a good explanation, please see [Continuous Delivery: lead time and cycle time](http://www.caroli.org/continuous-delivery-lead-time-and-cycle-time/). To compare the two metrics consider the following scenarios. Notice that `Lead Time` is the same for the pipelines in both scenarios, however the cycle time is much smaller in the second scenario due to the fact that the pipelines are running in parallel (higher `WIP`). This agrees with the formula `Lead Time = WIP x Cycle Time`:
Expand Down

0 comments on commit 45cc425

Please sign in to comment.