The Hardening Sprint That Was Not in the Framework
Eclipse Analytics has five Developers and runs two-week Sprints. For the last six Sprints, the team has reserved the final week of every second Sprint as a 'hardening Sprint' with no new features, only defect fixes and regression testing. The Product Owner accepts the practice because releases have been more stable, but velocity has fallen 22% and stakeholders see no new value during hardening. The team's Definition of Done says an item is Done when code is merged, unit tests pass, and a tester has executed a manual regression script. There are 14 open defects, 6 of them severity 1 or 2. The Scrum Master is asked by management to 'make the hardening Sprint official' so planning is predictable. The Developers say they cannot test everything in a two-week Sprint because the test environment is shared and the regression suite takes three days to run. Sprint Review has become a demo to visitors; the Product Backlog is not discussed.
1. Is the hardening Sprint consistent with Scrum? Explain your reasoning using Scrum theory and the purpose of a Sprint.
Read the worked answer
No - not as described. Scrum has one container for work and learning: the Sprint. A Sprint must end with a Done, usable Increment. A recurring 'hardening Sprint' that exists because the normal Sprint does not produce a releasable Increment is a symptom, not a framework element. It creates a second, hidden Definition of Done and makes the first Sprint's transparency false.
That does not mean all Sprints must add features. A Sprint Goal can legitimately focus on defect reduction, automation, or platform work - but the result still has to meet the Definition of Done and be potentially releasable. The test is whether the team could release at Sprint end without a separate stabilization phase. Here, the 22% velocity drop and 14 open defects show the team is paying for quality work later, with interest. The Scrum Master should not 'make hardening official'; that would legitimize the absence of a releasable Increment and reduce the pressure to fix the system. The better move is to treat the hardening work as evidence in the Retrospective and change the Definition of Done and engineering practices so each Sprint produces a releasable Increment.
2. What should the Developers do about the shared test environment and the three-day regression suite so that every Sprint can produce a releasable Increment?
Read the worked answer
Treat the environment and regression suite as product problems owned by the Developers, not as fixed constraints. Reasoning: a three-day manual regression inside a two-week Sprint consumes roughly 30% of one person's time, and a shared environment creates queues and unreliable feedback - both destroy the team's ability to finish a releasable Increment.
Concrete actions:
- Automate the regression suite around the highest-risk customer journeys first; do not wait for 100% coverage. Run fast tests on every change and the full suite at least daily.
- Make test environments reproducible (infrastructure as code, containers) and create ephemeral environments per branch or per feature; negotiate a dedicated integration environment if management controls funding.
- Shift testing left: Developers write automated tests at unit, integration, and API levels; testers coach and explore rather than execute scripts at the end.
- Reduce batch size so less regression is needed per change, and use feature flags to separate deployment from release.
- Add 'automated regression green' to the Definition of Done only after the team has built the capability; otherwise the DoD becomes fiction.
The team should present the cost of the current environment at the Sprint Review and ask the Product Owner to order automation work against feature work. That is a product trade-off, not an engineering excuse.
3. Rewrite the Definition of Done so it supports a potentially releasable Increment, and describe two measures that would show the change is working.
Read the worked answer
Rewrite the Definition of Done as a checklist the team can verify every Sprint, for example:
- Code is integrated to trunk at least daily and the CI build is green.
- Automated unit, integration, and regression tests for changed behavior pass.
- At least one peer reviewed the change (pairing counts); no sole gatekeeper required.
- No open severity 1 or 2 defects in the Increment.
- The Increment deploys to a production-like environment through the automated pipeline.
- Database changes are versioned and applied by the pipeline.
- Non-functional checks agreed with the Product Owner (performance, security, accessibility) pass.
- Release notes and operational runbook updates are included.
Two measures: (1) escaped defects per Sprint and their severity, and (2) the time from 'code complete' to 'releasable in a production-like environment' - the team's deployment lead time. Also track the percentage of items that meet the full Definition of Done at Sprint end and the capacity spent on hardening. If escaped defects fall and lead time shrinks without a hardening week, the change is working. The measures must be used to learn, not to punish.