Four magic numbers for measuring software delivery
- Lead time to validate, design, implement and ship a new valuable thing. Consider two types of lead time: (a) feature lead time: the time to move an item from high-level requirements to feature release and (b) deployment lead time: the time from merging to master to the component being in production.
- Deployment frequency, understood as number of times per developer per day you ship to production. Your deployment frequency may ebb and flow, from 5-10 on a busy day to none the rest of the week. Establish a baseline over 4 weeks: say, 1 production deployment per day on average.
- Change failure percentage, ie, the proportion of red deployments, bugs, alerts, etc. Defining change failure rate as bugs per production deployment over a given period, aim for about 10% or less with medium or high-priority of customer impact.
- Mean time to recovery/resolution. For mean time to resolution, aim for less than a working week.
- Considering feature lead time as a key performance indicator can help you break features up and deliver faster. This might also decrease lead time per deployment.
- Convert generic support tickets into bugs with customer impact implications so they can be tracked better. Make bugs more visible can also make bottlenecks in the resolution process more apparent.
- Count red production deployments and production alerts as a change failure.
Full post here, 9 mins read