Deployment management value streams, metrics and continual improvement
Domain 6: Value streams, metrics and continual improvement
This domain tests how deployment fits the service value chain and how to measure it without optimizing one number. Expect questions on value stream mapping, DORA-style metrics, and improvement actions.
Core rules
- Deployment sits mainly in design and transition and obtain/build, and feeds deliver and support. A value stream map shows demand, change authorization, build, test, deploy, verify, release, and support.
- Useful metrics: deployment frequency, lead time for changes, change failure rate, mean time to restore, deployment success rate, rollback rate, time to deploy, unauthorized deployment count, and environment availability. Use a balanced set; speed without stability is not improvement.
- Continual improvement starts with a post-deployment review: what failed, what was manual, where did waits occur, and what can be automated or shifted left. Smaller batches and better testing usually reduce failure rate.
- Avoid vanity metrics and individual blame. Measure flow and outcomes, and compare before and after changes.
Worked example
A team deploys 40 times a week but change failure rate is 25 percent. Deployment frequency alone looks excellent. Review shows large batches and late testing. The team introduces pipeline test gates, smaller releases, and canary checks. After two months, frequency stays high and failure rate falls to 8 percent. The reasoning: improvement targeted the constraint, test feedback, not the headline metric.
Traps
- Measuring only deployment speed.
- Ignoring failure and recovery metrics.
- Blaming individuals for deployment failures.
- Mapping a value stream without validating real waits and handoffs.