The Quarterly Hardening Sprint

Problem 1 - batching of quality work. A hardening Sprint exists because the Increment produced in Sprints 1–3 is not in a releasable state. That means the team's Definition of Done stops short of 'releasable', so what they inspect at each Sprint Review is not real. Inspection of a not-done Increment cannot produce useful adaptation.

Problem 2 - treating velocity as a target rather than a measurement. The chart is a transparency mechanism about a complex process. Asking to remove the dips is a request to make the data look better rather than to make the process better, which breaks the transparency leg that inspection and adaptation depend on.

The reasoning chain: empiricism requires transparency (the number reflects what actually happened), inspection (we look at it and see something uncomfortable), and adaptation (we change the process). Smoothing the chart skips straight to a comfortable artefact with no adaptation behind it - the exact failure mode the three pillars are meant to prevent. Note also that four escaped defects per release is the objective evidence that the hardening Sprint is not working as a safety net; the trend is unchanged across the nine Sprints.

Refuse the exclusion, and reframe the date.

• On the chart: excluding Sprints would hide the largest data point the organisation needs - that 25% of capacity is consumed by rework. Offer instead to add the hardening Sprints as a visible annotation and to present the escaped-defect trend beside the velocity chart. Transparency improves when the data gets richer, not when it gets filtered.
• On the date: a forecast is not a commitment. The responsible answer is a probabilistic statement built from the transparent history - e.g. 'with the current Definition of Done, we complete roughly X points per four Sprints; at that rate the remaining backlog is 9–12 Sprints, and that range widens if the Definition of Done changes.' Give the range, name the assumptions, and say what would narrow it.
• Escalate the real question: the CFO wants cadence predictability. The honest path to that is a Done Increment every Sprint, not a hidden hardening Sprint. That is a Definition of Done conversation, which is the team's call, not the CFO's and not yours.

Do not present the choice as 'the SM blocks management'. The SM's job is to make the trade-off visible so the people with the authority make it with accurate information.

The DoD must absorb the hardening work - typically adding deployed-to-production-like environment, integration/regression test suite passing, and whatever the release process actually requires - so every Increment is releasable and each Sprint ends with an inspectable outcome.

Before adoption, all of these must be true, or the team is just moving the failure:

1. Automation exists or is funded. If regression testing is manual and takes five days, adding it to the DoD makes every Sprint fail. The team needs an explicit, time-boxed investment in test automation, agreed with the Product Owner as backlog work.
2. The organisation's standard is respected. If the organisation already has a minimum DoD, the team's DoD must meet it. The team may strengthen it, never weaken it.
3. The team owns it. Developers create the DoD; the Scrum Master coaches and the Product Owner is consulted, but it is not imposed by the CFO or the SM. Imposed quality criteria are the first thing dropped under pressure.
4. Expect a velocity drop, and say so in advance. Folding testing into every Sprint reduces points per Sprint while it stabilises. Warn management before the chart moves, otherwise the new DoD is blamed for the old debt.
5. Expect an initial bulge of unfinished items. Some current 'Done' work will fail the new bar. The Product Owner should know this before the Sprint Review where it surfaces.