The Regulator Who Arrives at Sprint Review
Harborline is a payments platform. Six sprints into a nine-sprint release, a compliance officer begins attending sprint reviews. She points out that audit-logging requirements (who changed what, when, with immutable seven-year retention) were published five months ago and must be satisfied before the regulator's 1 October audit - eleven weeks away. The backlog contains no such items; the product owner ranked them low because no customer had asked for them. Fourteen features already released to production would need retrofitting, and the team's velocity is a steady 38 points per sprint against six sprints of committed customer work. The product owner proposes a four-week 'hardening sprint' at the end with no new features, and asks the Scrum Master to keep the compliance officer 'out of the team's hair' until then.
1. How should the team handle the compliance work that has just surfaced? Be specific about the backlog, planning and sequencing.
Read the worked answer
Make it visible first, then re-forecast. The work is real whether or not it is on the board, so the first move is to write it into the product backlog as an epic with acceptance criteria co-written with the compliance officer (immutability, retention period, who-changed-what are all testable).
The product owner still orders the backlog, but ordering cannot override a hard external constraint. Treat 1 October as a fixed date and re-run the forecast rather than defending the old plan:
- Capacity remaining: 6 sprints x ~38 = ~228 points.
- Retrofitting 14 features is likely to exceed the customer work that must now be deferred. Estimate it at epic level and slice it - do not estimate 14 retrofits individually before the first one is built.
- Sequence the logging foundation first, so work delivered in sprints 7-9 is built right rather than retrofitted later, and so the biggest unknown is resolved early.
- Retrofit highest-risk flows (payments, refunds) before low-risk ones.
The 'hardening sprint' proposal should be rejected: it banks four weeks of unfinished quality work into a big-bang integration at the riskiest moment, hides the cost from the sponsor, and abandons 'done' as the team's normal state. Quality attributes belong inside each sprint's definition of done, not in a separate phase.
Finally, the forecast must change publicly: state which committed customer features slip and by how much. Absorbing the gap silently is how teams end up doing neither thing well.
2. What should the Scrum Master do about the product owner's request to keep the compliance officer away from the team?
Read the worked answer
Decline the framing, then fix the channel. A Scrum Master removes impediments to collaboration; gatekeeping a stakeholder is not removing an impediment, it is relocating it. Two things are true at once: the team needs focused time, and the compliance officer is a legitimate stakeholder with non-negotiable requirements.
The compliance officer appearing unannounced at a sprint review is a symptom of a missing engagement channel, not of an intrusive stakeholder. Concrete actions:
- Formally invite her to sprint reviews as a stakeholder, and to refinement sessions for the compliance epic so criteria are written once, not argued twice.
- Set a predictable 30-minute weekly check during the retrofit so questions have a home and do not arrive as interruptions.
- Coach the product owner on what failed: the requirement existed five months ago. Add regulatory/compliance to the stakeholder map and a standing environmental scan at each release planning session.
Where the Scrum Master should shield the team is in routing all requests and priority changes through the product owner, so developers are not adjudicating between competing demands mid-sprint. That is protection of focus, not exclusion of a stakeholder. Protecting the team from bad news is not in the role.
3. The team estimates the retrofit at roughly 100 points on top of committed work. What does the team commit to, and what does the product owner tell the sponsor?
Read the worked answer
Commit to a forecast with a range, and push the trade-off to the person who owns it.
Recent velocity is 38 points with a plausible range of about 34-42. Over six sprints that is roughly 204-252 points of capacity. Committed customer work plus ~100 points of retrofit does not fit; something is going to be cut, and the team should not choose silently which quality or which customer promise breaks.
What the product owner presents to the sponsor:
- The constraint (regulatory, dated, non-negotiable) and the estimated size.
- The capacity arithmetic, using observed velocity rather than a hoped-for number.
- Options, with consequences: defer features A and B; reduce the retrofit to the regulated flows only and accept documented risk (sponsor's call, in writing); add a dedicated pair to the retrofit (with realistic ramp-up, not a doubling of velocity).
- A recommendation, and the date of the next checkpoint where the forecast will be refreshed.
The team commits to the sprint goal and the first slice - building the logging foundation - not to an unvalidated 100-point number six sprints out. Agreeing to an impossible date to avoid an uncomfortable conversation converts a scheduling problem into a compliance failure. Record the accepted risk so it is owned at the right level.