How should Product and Engineering decide whether a Feature is ready to release?
A Feature is ready to release when its intended user journey is worth exposing, its agreed quality and operational conditions are met, and the team can detect and respond to harm. Product confirms value, scope and communication; Engineering confirms technical evidence, deployment and recovery. The decision should consider the actual release context and risk. A completed ticket or passing test suite alone is insufficient.
Key takeaways
- Separate completion of development from the release decision.
- Check the intended journey, quality conditions and operational support.
- Match rollout and recovery to the risk of the change.
- Record residual risk and who accepts it.
Teams often mark a Feature complete when code is merged, then discover that support, data migration or customer communication was not ready. Delaying every release until a formal ceremony creates a different cost. Product and Engineering need a short, evidence-based release decision matched to the Feature’s consequence.
Define what ready means for this Feature
Readiness has several parts. The Feature should address a worthwhile user need for the intended population, behave as agreed and fit the surrounding service. Product checks the value proposition, scope, customer impact and communication. Engineering checks implementation, integration, security, data, accessibility, reliability and support as relevant. The team should know what remains uncertain and what evidence could reveal harm. The decision is about this release, not an abstract statement that software is perfect.
Use established completion and release controls
Use existing quality standards, acceptance evidence, review and trusted build pipelines. In Scrum, the Scrum Guide says an Increment must meet its Definition of Done and that the Sprint Review is not a gate to release. Other teams may use different frameworks, but the same distinction between completion and exposure is useful. Google's release engineering account describes repeatable builds and testing the release artefact. Apply controls proportionately to your own environment.
Choose exposure and observe the result
Decide who first sees the change, which indicators will be watched and who can pause or reverse it. A feature flag or phased rollout can reduce exposure, provided dependencies and data changes are also reversible. Google SRE's canary guidance describes observing a small initial population before wider release. This does not make every change safe; low traffic may hide faults. Product and Engineering should agree when to expand and what customer evidence they will review afterwards.
Resolve exceptions with named owners
If a condition is unmet, say whether release can be narrowed, delayed or redesigned. Engineering should explain technical consequences; Product decides whether a reduced journey remains worthwhile. A risk owner or specialist must accept material exceptions within the organisation's rules. Record the decision, evidence, residual risk and recovery owner. AI may help summarise a checklist, but generated assurance cannot replace inspection of the actual change or approval by accountable people.
Example
Hypothetically, a payments team completes a new receipt view. Product confirms the selected customer group and support guidance. Engineering verifies the migration, accessibility checks and monitoring, then exposes the view to a small cohort. The team has an owner who can disable it if receipt mismatches appear and reviews customer feedback before wider release.
FAQs
-
Does passing the Definition of Done mean release is automatic?
It means the Increment meets agreed quality measures in Scrum; release timing and exposure still need product and operational judgement.
-
Should every Feature have a formal go/no-go meeting?
Use an explicit decision, but make the process proportionate; routine low-risk changes can follow a pre-agreed automated route.
-
What if rollback is impossible?
Reduce initial exposure, strengthen pre-release evidence and plan a compensating recovery route with the relevant owners.
