The Sponsor Who Wants a Date
A retail bank is building a mobile account-opening flow. The steering committee sponsor demands a fixed launch date eleven weeks out, tied to a regulatory window. The team has completed three sprints of a discovery-and-build effort. Estimates for the remaining backlog range from 140 to 260 points depending on whether identity verification integrates with the incumbent vendor or requires a custom build; that decision is blocked on a vendor security review with no committed date. Two of the three sprints missed their commitment, once because a dependency on the core banking team surfaced late. The team's average velocity is 24 points per sprint with a range of 18 to 29. The product owner has a ranked backlog but has not yet split the identity-verification epic.
1. How should you respond to the sponsor's fixed date request?
Read the worked answer
I would neither refuse the date nor promise it. I would convert the request into a transparent forecast with an explicit decision point.
First, quantify the uncertainty honestly. At 24 points per sprint over eight remaining sprints, capacity is roughly 192 points, with a plausible range from about 144 to 232 given the observed 18-to-29 spread. The remaining backlog of 140 to 260 points straddles that capacity. The date is achievable only in the low end of the estimate range, and the range is wide precisely because the vendor decision is unresolved.
Second, make the dependency the center of the conversation. The security review is the single biggest driver of the estimate spread. I would ask the sponsor to use their authority to get a date for that review, because that is the highest-leverage action available and it is outside the team's control.
Third, propose a date-protection plan: a fixed date with variable scope, where the minimum viable regulatory-compliant flow is defined and lower-priority features are explicitly deferrable. I would present the forecast as a cone of uncertainty narrowing after the vendor decision, not as a commitment the team cannot support.
2. The identity-verification epic is unsplit and blocking forecast precision. How do you address it?
Read the worked answer
An unsplit epic that spans the largest uncertainty in the backlog is the reason the forecast range is so wide. Splitting it is not administrative tidying; it is the mechanism for reducing forecast error.
The first split should follow the decision boundary, not the feature list. Separate the work that is common to both paths from the work that only exists if the custom build is chosen. The common slice, such as the user-facing capture flow and the data contract, can be refined, estimated, and started now. The vendor-integration slice and the custom-build slice stay as thin placeholders until the security review resolves.
Second, I would run a short spike with a timebox to characterize the custom-build path enough to narrow its estimate. A spike is cheaper than guessing across a 120-point spread.
Third, I would bring the product owner and the core banking dependency owner into a joint refinement session. The late-surfacing core banking dependency in an earlier sprint suggests the team's dependency mapping is incomplete, so I would add an explicit dependency check to refinement and to sprint planning. After these steps the forecast range should narrow, and the sponsor gets a more honest date rather than a false one.