Make Deployment a Business Decision

Some teams create a “stabilization” window after a sprint because features are half done, half tested, or half documented.

This delivery delay frustrates customers.

A better approach is to have systems in place that enables our software to always be technically deployable at the end of every iteration. From the builders’ point of view that means code is clean, tests pass, documentation up to date, and the implemented stories are stabilized.

When we meet that bar, deployment becomes a business decision—not a technical scramble.

Discussions for your team

• Is “deployable” listed as a criteria as a prerequiste before work can be labeled as “done”?
• Are our stories small enough to finish fully and be deployable?
• Can the team verify technical readiness and overall deployability quickly?
• What changes can we make to eliminate the need for a stabilization windows?