Done but Not Releasable
Atlas Logistics has a six-person Scrum Team delivering a customer portal in two-week Sprints. The team marks a Product Backlog item Done when code is merged and unit tests pass. To release, Operations requires a 60-step manual deployment runbook, a database migration performed by a DBA outside the team, a manual smoke test, and approval from a change advisory board that meets on Thursdays. Production deployments happen once a month. The team's last three Sprints each produced an Increment that passed internal review, but the release lead time is 12 working days and stakeholders saw no new value for six weeks. A recent deployment failed because a migration script was missing; the team spent two days restoring service. Management wants the team to 'go faster' and suggests skipping the smoke test. The Product Owner asks whether the team can claim an item is Done before it is in production. The Developers say deployment is 'Ops work' and that they are not allowed to change the runbook.
1. What is wrong with the team's use of Done and with its understanding of a potentially releasable Increment?
Read the worked answer
The Definition of Done stops too early. 'Code merged and unit tests pass' describes only part of the product development flow; the team is declaring Done while 60 manual deployment steps, a DBA migration, a smoke test, and a change board remain. That is not a potentially releasable Increment. In Scrum, Done means the Increment meets the team's Definition of Done and is usable; 'potentially releasable' means the team could release it now without additional work, even if the organization chooses not to deploy. It does not require deployment every Sprint, but it does require that deployment is not a separate project.
The consequences are visible: 12 working days of release lead time, six weeks before stakeholders see value, and a failed deployment caused by a missing migration script. The team cannot inspect the real risk in the Sprint Review because the risk lives after the Review. The Product Owner also cannot make good ordering decisions when 'Done' and 'released' are separated by a month. Skipping the smoke test would remove a safety check without fixing the system. The right response is to bring release work into the Definition of Done and the Sprint, not to lower the bar.
2. What practices and agreements should the team adopt with Operations to shorten the release lead time from 12 days?
Read the worked answer
Treat release as part of the product, not a handoff. Agreements and practices:
- Automate the deployment pipeline end to end, including database migrations; version migration scripts and run them as part of deployment, with rollback tested.
- Infrastructure as code so environments are reproducible and the 60-step runbook becomes an executable pipeline.
- Automate the smoke test rather than skipping it; keep a small, fast set of production checks.
- Shift the change advisory board from per-change approval to a risk-based, pre-approved standard change for low-risk releases, with an audit trail. Invite Ops to refinement and Sprint Review.
- Use feature flags to separate deployment from release and reduce risk.
- Include an Operations representative in the Scrum Team or a closely collaborating DevOps group; the team should be able to deploy to production or a production-like environment.
- Redefine Done to include deployability and operational readiness.
Measure lead time, deployment frequency, change failure rate, and time to restore. The goal is not to bypass controls but to make the control automatic and continuous.
3. Plan the next Sprint to prove the team can produce a releasable Increment. What would you put in the Sprint Backlog and how would you measure success?
Read the worked answer
Use one Sprint as a proof, not a big-bang transformation. Sprint Goal: 'A thin customer-portal change can be deployed to production through an automated pipeline with a database migration and automated smoke test.' Sprint Backlog items: select a small, low-risk backlog item; automate its build and deployment stages; pair a Developer with an Operations engineer to convert the relevant runbook steps into pipeline code; version and test the migration; automate the smoke check; rehearse a failed deployment and rollback; update the Definition of Done with the new evidence.
Measure success by: deployment lead time for that item, whether deployment required manual steps, whether the migration was applied automatically, smoke-test duration, and whether the team - not only Ops - performed the deployment. Also track the change failure rate and time to restore during the rehearsal. If the proof works, the team presents it at the Sprint Review and agrees with the change advisory board on a standard-change path for similar releases. The point is to demonstrate a releasable Increment and learn where the pipeline breaks, not to deploy everything at once.