Fixed Price, Fixed Scope, 'Fixed' Scrum
You are a Professional Scrum Trainer delivering a two-day Applying Professional Scrum course to 14 people from a government IT supplier. The day before, the delivery director emails: "The team already knows the ceremonies. Skip the theory and show us how to stabilise velocity so we can bid fixed-price contracts with confidence." On day one, three signals appear. In the forecasting exercise, every table plans to 100% of capacity and treats the Sprint Backlog as a promise of a date. The team's Scrum Master is also the director's deputy and chairs the Daily Scrum. The Definition of Done reads "code reviewed and merged to the test branch", and the Sprint Review is described as the point where the client signs off scope. In the break, two developers ask quietly whether "all this empiricism stuff" is exam theory or something they are actually supposed to use. The room is polite, attentive, and clearly expects you to make their existing process faster.
1. The director's request conflicts with the course's learning objectives. How do you respond in the moment, and what do you actually change?
Read the worked answer
The request cannot be granted as written, but it is not an attack - it is the most useful diagnostic in the room. Separate the ask into two parts.
The first part is the course's learning objectives. These are fixed: a Scrum.org course is delivered against defined objectives, and "skip the theory and teach velocity stabilisation" removes the foundation that makes the rest of the course coherent. The second part is emphasis and framing, and that is yours. Velocity stability is not a lever you pull; it is a property that emerges from a stable system with a real Definition of Done, a consistent Sprint length, and short feedback loops. Bidding fixed-price against a range rather than a promise is a legitimate and valuable topic.
So accept the underlying business need - "you need numbers you can bid with" - and reframe the route, then promise a concrete slot: the final 45 minutes on forecasting under uncertainty, using their own simulation data. That is contextualisation, not a compromise of standards. What would compromise standards is spending two days teaching people how to convert empirical delivery into predictive commitments, which would make the class a rehearsal for their current problem.
After the class, tell the director plainly what you did and why, and offer a short follow-up with the sponsor. Do not argue it in front of the room: your credibility depends on serving the learners' real problem, not on winning against their boss.
2. Design a 45-minute exercise, using only the class's own data, that makes the cost of 100% capacity planning visible.
Read the worked answer
Use their own numbers. A trainer's opinion is easy to dismiss; their own data is not.
Step 1 (10 min). Ask each table to write, from the morning simulation, what they planned per person per day and what actually got finished. Tabulate it where everyone can see it.
Step 2 (10 min). Introduce one realistic shock - someone is ill for two days, or a test environment is down for a day. Ask each table to re-forecast. Almost all will have no buffer, so the forecast collapses immediately.
Step 3 (15 min). Re-plan the same work with 70–80% planned capacity and a rule that the Sprint Goal can still be met without the missing person. Compare the two plans: the second has a lower planned total but a far higher probability of meeting its goal.
Step 4 (10 min). Debrief with three questions: When did you last have transparency about actual capacity? What did inspection tell you? What would you adapt next Sprint?
The move is discovery-based - you supply the questions and the shock, they supply the evidence. Close by naming the three pillars against what they just did, so the theory becomes a description of their experience rather than a lecture. Then connect it: a fixed-price bid built on a range plus a transparent Definition of Done is defensible; a bid built on 100% capacity is a promise nobody can keep.
3. Name two things you must not do in this class, and explain why each would be a professional failure.
Read the worked answer
Do not make an example of the deputy Scrum Master in the room. The deputy is a participant, and the class's psychological safety depends on people being able to describe how they actually work without being corrected in public. If the Daily Scrum is used as a case, anonymise it.
Do not teach "how to hit a committed velocity". It would be technically wrong, it would validate the director's model, and the class would leave believing Scrum is a delivery-commitment machine with new vocabulary. That is the precise opposite of the course's purpose.
Do not quietly drop the empiricism content because the client is paying and the room is polite. Silent omission is a bigger standards failure than an open negotiation: the learners paid for a course with defined objectives, and they will be assessed against that knowledge.
Do not turn two days into free consulting for the director. Their fixed-price problem is real, but solving it would consume time owed to the other thirteen people and would blur the boundary between a course and an engagement.
What you should do is record the conflict in your own notes, raise it with the director afterwards, and offer a follow-up conversation. Documenting the negotiation protects the learners, the client relationship, and you.