Aligning a regulated release window with Sprint length
Meridian Pay is a regulated payments company running two-week Sprints across four Scrum Teams. Marketing commits campaign launches to retailers with three-week notice, and the compliance team requires a signed-off release package at least five working days before any customer-facing change goes live. The Product Owner has proposed moving the teams to three-week Sprints so that each Sprint ends exactly when a release package is due, arguing this removes the "wasted" mid-Sprint replanning. Velocity data show the teams average 62, 55, 71 and 48 story points per two-week Sprint, with roughly 15 percent of items per Sprint carried over. In the last three Sprints, urgent compliance fixes arrived mid-Sprint on average four times per team and were absorbed without changing the Sprint Goal. A senior manager has asked you, as the Scrum Master of one team, to endorse the three-week change at the next leadership review and to explain how release cadence and Sprint cadence should relate.
1. The senior manager wants your endorsement of three-week Sprints. Assess the proposal: what would you recommend, and on what grounds?
Read the worked answer
Separate the variables that legitimately drive Sprint length from the one being used here. Sprint length is chosen by the team, capped at one month, and should be driven by uncertainty, how often the team needs feedback, and the cost of coordination. Here the driver is an external release and compliance process, not the work itself.
Against the change:
- Feedback frequency drops by about a third, in a domain where compliance requirements are visibly volatile (four unplanned items per team per Sprint).
- Velocity becomes incomparable with history and across the four teams, just as the organisation is already (wrongly) comparing them.
- Aligning Sprint end to release date invites the Sprint to become a mini-waterfall with a closing release crunch.
The stated justification is weak. The "wasted replanning" is caused by roughly four urgent compliance fixes per Sprint landing on top of fully committed plans - a capacity and intake problem that a longer Sprint makes bigger, not smaller. Absorbing them without touching the Sprint Goal is only legitimate if the Product Owner and team renegotiate scope explicitly.
Recommendation: keep two weeks, and treat the compliance arrival pattern as the real problem - reserve explicit capacity for regulatory work, agree with the Product Owner what triggers renegotiation of Sprint scope, and decouple release from Sprint end. Endorse a decision only after the team, not the manager, has weighed the trade-off.
2. Explain to the leadership review how release cadence and Sprint cadence should relate, including what the Sprint Review is and is not.
Read the worked answer
Release is a business and risk decision that does not have to coincide with a Sprint boundary. A Scrum Team produces a usable Increment every Sprint - potentially several times a Sprint - and the organisation decides when to put it in front of customers. Two-week Sprints with a quarterly regulated release are perfectly compatible; two-week Sprints with a release gate bolted onto Sprint end are not, because they turn the Sprint into a delivery deadline.
The Sprint Review is an inspection point: stakeholders and the team inspect the Increment and the emerging environment, and the Product Backlog is adapted as a result. It is not an acceptance gate, not a sign-off stage, and not the moment the release package is produced. If the compliance evidence takes five working days, that work belongs inside the Definition of Done for the affected items, inside the Sprint - not in a separate hardening phase after the Sprint ends.
Practical advice for the review: build the release-evidence steps into the definition of done and automate what can be automated; release on demand from whatever Increment is compliant; and measure the lead time from when an item enters the Sprint, not from "done", so the cost of any post-Sprint hardening is visible. If auditors genuinely require one signed release per quarter, state that as a constraint on release, not on Sprint length.
3. Leadership notes the four teams deliver 62, 55, 71 and 48 points. What can they legitimately infer, and if a three-week cadence were ever adopted, how should forecasting change?
Read the worked answer
Almost nothing cross-team. Story points are a relative, team-specific estimate shaped by team size, domain complexity and estimation habits; comparing 71 with 48 says more about how each team estimates than about value delivered. Treating the numbers as a league table creates incentives to inflate estimates and to resist anything that would lower recorded velocity, such as a stronger Definition of Done.
What leadership can legitimately use: each team's own trend, throughput of backlog items, cycle time, carryover rate, and outcome measures such as defect escapes and time to production.
On changing cadence: velocity must be re-baselined, never multiplied. A team averaging 60 points per two-week Sprint does not average 90 per three-week Sprint, because estimation granularity, ceremony overhead and the size of items all shift. The sound approach is to re-forecast from the first three Sprints at the new length and to supplement with throughput-based forecasting (for example, counting how many items of a given size class complete per Sprint). The 15 percent carryover is also a planning signal: forecasts should be built on capacity net of a realistic buffer, especially given four unplanned compliance items per team per Sprint.