The sprint review went well. The increment was demoed, stakeholders asked good questions, two stories were added to the backlog, one was re-ordered, and somebody from platform mentioned that the auth migration would slip a sprint. Everyone left with the same slide they came in with: Release 4.2 — June 7.
Nobody lied. Nobody was careless. The review did exactly what it is designed to do. It just never asked the one question that everything discussed in the room was quietly answering: what did this sprint do to the committed release date?
What a sprint review is for
A sprint review is the Scrum event where the team and its stakeholders inspect the outcome of the sprint and decide what to adapt next. It is a working session, not a demo: the increment is shown, progress toward the product goal is discussed, and the product backlog is adjusted in the light of what was learned. Earlier editions of the Scrum Guide went further and had the Product Owner project likely delivery dates from progress to date. That is the part most reviews have dropped, and it is the part that matters most to anyone who was promised a release.
Why the date survives every review unchanged
At PI planning or release planning, the team voted confidence in a date. That confidence vote was expert engineering judgment: the people who know the codebase, the dependencies and each other looked at the plan and said “we can do this.” It was right on the day it was taken.
Then the weeks started. And a sprint review is where the evidence of the three things that erode a release date shows up, one sprint at a time:
- Scope creep. “Can we also…” becomes two new stories in the backlog adaptation. Each one is reasonable. Together they add days nobody priced.
- Dependencies surfaced too late. “Platform says auth slips a sprint” is a dependency the vote never saw. It changes sequencing, and sequencing changes the date.
- Capacity changes. A developer rotating to support, a hire who starts late, a holiday week nobody planned around. Throughput moves before anyone says so.
The review sees all three. It records them as backlog changes and action items. What it does not do is convert them into days against the committed date, so the slide stays at June 7 until the sprint where it can’t.
Add one standing item to the sprint review agenda
You don’t need a new meeting. You need one question, answered with evidence, at the end of every sprint review:
“Given what we just changed, how confident are we now in the committed date, and how many days are we from our 85% date?”
Answering that by hand is where it falls apart. Re-running a forecast means re-reading throughput, recounting remaining scope, adjusting for who is actually available, and doing it thousands of times to get a real range. Teams don’t skip it because they don’t care. They skip it because it takes an afternoon and the review is an hour.
The team owns the assumptions. The forecast does the arithmetic.
This is what Advanced Release Planning for Jira is built for. The team decides the inputs: which throughput window reflects how it works now, whose capacity counts, what is in scope for the Fix Version. The app runs Monte Carlo simulation over the team’s real Jira throughput and keeps the committed date on a live confidence band (50/85/95%), so the answer to the review question is already on screen when the review starts.
In practice the last ten minutes of the review look like this:
- Read the band. “Committed date June 7. Confidence at June 7 is now 62%, down from 85% at the vote. P85 is June 18.”
- Name the driver. Tie the drop to what changed this sprint: two stories added to the Fix Version, and a blocking dependency that moved out a sprint.
- Decide while it is cheap. Cut or defer scope, resequence the dependency, or renegotiate the date with stakeholders who are already in the room.
That is still the team’s judgment at work. The difference is that the judgment is exercised on current evidence every two weeks, instead of on the evidence from the day of the vote.
Sprint review vs demo: the date is the difference
Practitioners have long argued that a sprint review is more than a demo. The committed date is a good test of that. A demo shows what was built. A review should also show what the sprint did to the promise. If your review ends without anyone reading confidence at the committed date, it has quietly become a demo with a longer agenda. Pairing it with the velocity chart tells you how the last sprint went; the forecast tells you what that means for the next ten. If the date is presented upward on a milestone chart, the band tells you whether the diamond still belongs where it is.
Keep the vote live
A confidence vote is a snapshot. The sprint review is the one recurring moment when the team and its stakeholders are together with the latest evidence. Use it to keep the vote live: read the band, name what moved it, and renegotiate before the slip instead of after it. How the forecast is built is in the probabilistic release forecasting feature doc.
Bring a live confidence level to your next sprint review →
1 Comment
Leave your reply.