A phased delivery strategy divides a larger change into sequenced stages, beginning with a narrower release and expanding scope after each stage proves stable. It can unblock dependent work early while preserving a path toward the complete feature. section 3.2.4
Apply the strategy by:
- Define a small first stage that delivers useful progress or removes a dependency. section 3.2.4
- For production deployments, progress from alpha or beta staging to production-like pre-production, then to production. section 12.2.4
- Add bake time between stages, such as 24 hours in pre-production, to check stability before advancing. section 12.2.4
- Use canary deployments to expose changes gradually to a subset of users and advance based on feedback and stability. section 12.2.4
- Pair feature toggles with staged launches when useful, enabling, disabling, experimenting with, or quickly deactivating features. section 12.2.4
Removing a cross-team dependency
A promotion system needs royalty calculations. The teams agree to include the use case in the royalty team’s roadmap, contribute engineering help, and deliver a trimmed-down phase one before completing the full feature in phase two. The first stage unblocks the promotion team and removes the dependency while creating groundwork for later enhancements. section 3.2.4
