Thirty-Eight Small Tweaks
You manage a hybrid engagement: a 12-month fixed-price contract with a customer product owner embedded in a Scrum team. In five sprints the product owner has added 38 backlog items, 22 of them accepted as "just a small tweak" without estimates. Burn rate is up 18%, velocity has stayed flat at about 30 points per sprint, 3 of 5 sprint goals were missed, and the contract's change-control clause has never been used. The customer's account manager says raising a change order would damage the relationship. Your own sponsor says: "Keep the customer happy - it's only small stuff." Two contract milestones depend on the original scope being complete.
1. Is this scope creep, and what evidence do you need before acting?
Read the worked answer
Not all of it is creep - and that distinction is the whole argument.
Legitimate: the product owner reprioritising within contracted scope, swapping items of roughly equal size. That is agile working as intended.
Creep: net additions consumed without trade-off. The test is arithmetic:
- Size the 38 items in story points.
- Split them into in-contract versus genuinely new.
- Compare against capacity: 5 sprints × 30 points ≈ 150 points.
- Show the milestone forecast with and without the new items.
The 22 unestimated items are the tell: work accepted without sizing cannot be traded off. Burn up 18% with flat velocity also suggests capacity is being consumed by rework or context switching, which the data will confirm or rule out.
Why evidence first: "the customer keeps adding things" is an opinion and invites defensiveness. "This consumes 22% of capacity and puts milestone 2 at risk by three weeks" is a trade-off the product owner and account manager can act on.
2. How do you handle the customer relationship and the contract together?
Read the worked answer
The relationship and the contract are not in opposition - an unmanaged fixed-price contract ends in a dispute that damages the relationship far more.
Approach:
- Bring the data to the product owner and account manager, framed as protecting their milestones, not as policing their requests.
- Offer three options: (a) one-in-one-out prioritisation within existing capacity; (b) a formal change order with an estimate and price for genuinely new scope; (c) explicit deferral of the new items to a phase after the contract milestones.
- Make the change-order route light: a one-page estimate and approval, not a procurement event. Most resistance comes from the perceived weight of the process.
- Address the sponsor separately with the same numbers: "happy customer" and "missed contractual milestones" are not both achievable at current capacity.
Tone: problem-solving, not blame. The failure is in the working agreement - allowing unestimated items in - not in the customer's ambition. Document agreed changes so the contract status is reconstructable.
3. What changes to the team's way of working would prevent recurrence?
Read the worked answer
Fix the entry point, not just this sprint.
- Definition of Ready: no item enters a sprint without an estimate and acceptance criteria. This single rule closes the "it's just a small tweak" loophole.
- Capacity reservation: ring-fence a portion of each sprint for contracted scope; variable work uses the remainder.
- One-in, one-out rule: the product owner must remove or defer something of comparable size when adding.
- WIP limits on in-flight analysis and development to stop context switching.
- Transparency at sprint review: show cumulative scope added versus the contract baseline and the trend of unplanned work.
- Measures to watch: percentage of sprint capacity consumed by unplanned or out-of-contract items, number of change orders raised, milestone forecast variance.
- Retrospective: ask why small tweaks were accepted without estimates - usually the team lacked the confidence or the data to say no.
Why: the escalation is a one-time correction; the definition of ready and the capacity reserve are what stop the same conversation recurring in sprint seven.