A Promise Made at a Conference
BrightCover sells claims software to insurers. Halden Group is 18% of revenue and renews on 1 October, nine weeks away. At a trade conference the Product Owner learns that a sales director has publicly promised Halden a self-service claims portal live for that renewal, with a GBP 200,000 penalty clause if it is not. The team has never been asked to scope it; their rough view is five months of work at current capacity. The current Sprint Goal concerns claims triage. The sales director has also begun attending Sprint Reviews and giving instructions directly to Developers, and two Developers have started acting on them the following Sprint. Halden's operations lead has offered to be a pilot user.
1. How should the Product Owner respond to a commitment made on their behalf, and what should they bring to the conversation?
Read the worked answer
The Product Owner owns ordering and is the only person who can commit the Scrum Team's capacity. A promise made outside that accountability is not a plan; it is a risk. Do not absorb it silently, and do not refuse flatly in public.
Book a session with the sales director, Halden's operations lead, and someone who can vary the contract. Bring evidence, not opinion:
- A capacity-based forecast: at recent throughput, what is realistically Done by 1 October, expressed as a range.
- A thin slice that serves the renewal's actual purpose - for example Halden customers submitting a claim and receiving an acknowledgement - which may satisfy the clause's intent without the full portal.
- The cost of the penalty weighed against the cost of pulling the team off triage work, and what would be dropped as a result.
Then let the commercial owners choose between narrowing scope, moving the date, or accepting the penalty. The PO's job is to make the trade-off explicit, not to make it disappear.
2. The sales director bypasses the Product Owner and gives instructions directly to Developers. What should happen?
Read the worked answer
Feedback at the Sprint Review is exactly what the event exists for. The problem is not that the sales director speaks; it is that instructions bypass the Product Owner and land directly in Developers' work.
Three moves:
- The Scrum Master coaches the pair on decision rights, ideally before the next Review rather than in the moment. Ordering sits with the Product Owner; Developers take work from a Sprint Backlog they own.
- The Product Owner makes the legitimate channel attractive. Every request raised at the Review gets captured visibly in the Product Backlog, with an explicit ordering decision and a reason, within a Sprint. Stakeholders whose input is handled stop routing around the process.
- If it continues, this becomes a management issue rather than a facilitation one - the PO and SM take it to whoever owns the sales director's objectives.
Do not solve it by excluding the sales director from Reviews. For an account worth 18% of revenue, that stakeholder belongs in the room.
3. How should the team make progress visible over the next nine weeks so 1 October is not a surprise?
Read the worked answer
Make every Sprint end with something Halden could actually touch, and make forecasting a habit rather than a one-off.
- Tighten the Definition of Done for this work to include 'deployable to the pilot environment and usable by a Halden operations user'. Anything short of that is not progress toward 1 October, however many points it burns.
- Invite Halden's operations lead to every Sprint Review as a pilot user and have them try the Increment live. Their feedback is worth more than a status slide, and it also builds the case for a narrower scope.
- Publish a rolling forecast with a range based on observed throughput, plus a visible list of risks and dependencies - security review, data migration, contract wording. Update it every Sprint, good news or bad.
- Surface the penalty exposure early to whoever owns it. A surprise on 25 September is a failure of transparency; a warning on 1 August is a decision.