Velocity Up, Quality Down
An insurance quoting team of five Developers has been under pressure to show progress. Two Sprints ago, before a major demo, they redefined their Definition of Done: integration tests and accessibility checks were moved to a 'hardening Sprint' after release. Reported velocity rose from 28 to 46 story points per Sprint. The Product Owner reported 46 to the steering committee and committed to a release in four weeks based on that number. Since then 31 defects have escaped to production, about 40% of items marked Done need rework, and 120 story points of scope remain. At the last Sprint Review the team demonstrated features that did not run end to end in the staging environment. The steering committee now asks why velocity went up while quality went down, and whether the release date still holds.
1. Explain to the steering committee what weakening the Definition of Done has done to velocity, transparency and the forecast.
Read the worked answer
The velocity rise is an accounting change, not an increase in delivered value.
- The Definition of Done is the formal description of the state of the Increment when it meets the quality measures required for the product. If the organization has no standard, the Scrum Team creates one; either way, it is not a knob to turn down before a demo.
- By moving integration and accessibility checks out of the Definition of Done, the team started counting items as Done that were not Done. Velocity is the sum of work that meets the Definition of Done, so 46 is not comparable with 28; the two numbers measure different things.
- Consequences: transparency is destroyed, because 'Done' no longer means what stakeholders think it means. The forecast built on 46 is built on invalid data. Work that is not Done returns to the Product Backlog, not to a hardening Sprint after release.
- Demonstrating features that do not run end to end at the Sprint Review compounds this: stakeholders were shown something other than a usable Increment, so their inspection could not be honest either.
The message to the committee: quality is not a variable to trade against the date at the reporting layer. The 46-point figure should be withdrawn, the restored Definition of Done applied, and the forecast rebuilt from real throughput. That is uncomfortable now, but it is far cheaper than discovering it during the release.
2. How should a credible forecast be rebuilt for the remaining scope and the four-week release, and what options should be put to the Product Owner?
Read the worked answer
Restore the Definition of Done first, then forecast from real throughput and present options rather than a single date.
Steps:
- Reinstate the full Definition of Done, including integration tests and accessibility checks. Until that is in place, no throughput number is meaningful.
- Rebuild the backlog honestly: the 120 points of remaining scope is not the whole job. Add the rework of the roughly 40% of items marked Done and the 31 escaped defects as backlog items, and let the Product Owner order them.
- Re-baseline throughput using Sprints that met the full Definition of Done. The realistic figure is likely below 46 and may temporarily be below 28 while rework is paid down, because paying down debt consumes capacity that produces no new scope.
- Produce a range, not a point: a burn-up of Done work over the next Sprints with an explicit confidence statement and assumptions. Re-forecast at every Sprint Review.
Options for the Product Owner to take to the steering committee:
- Reduce scope to the minimum releasable set and hold the date.
- Hold scope and move the date.
- Add capacity, accepting that new people slow an existing team in the short term.
- Release a smaller Increment earlier, if it is genuinely Done and useful.
Quality is not on the list as a trade-off for the team to make quietly. The Product Owner decides among these with the stakeholders; the team supplies the evidence and does not promise a date it cannot forecast.
3. What should happen at the next Sprint Review and Retrospective, and how should the escaped defects be handled?
Read the worked answer
Show the truth at the Review, and fix the system in the Retrospective. Do not present undone work as done.
At the Sprint Review:
- Demonstrate only what actually runs end to end in staging. Explain what is not Done and why, and present the restored Definition of Done, the rework and defect data, and the rebuilt forecast range.
- This is what the Sprint Review is for: inspecting the outcome with stakeholders and adapting the Product Backlog together. It is not a compliance demo, and hiding the quality position would repeat the original failure at a larger scale.
- Give the steering committee the options from the forecast so it can make an informed decision about scope and date.
At the Retrospective:
- Find the root causes of the weakened Definition of Done: demo pressure, missing automated integration tests, no accessibility tooling, no continuous integration, unclear that the Definition of Done is not negotiable.
- Agree a small number of concrete improvements with owners: automate integration tests and put them in the Definition of Done, add accessibility checks to the pipeline, add test data and environments, and agree how the team responds to date pressure next time.
- Focus on the system, not on blaming individuals; the pressure came from outside the team as much as inside it.
The defects themselves belong in the Product Backlog, ordered by the Product Owner against new features. Some will be must-fix before release; the team estimates them. A permanent 'hardening Sprint' is not a substitute for a real Definition of Done, and the Scrum Master should say so to management.