The mid-Sprint favour and the DoD that doesn't apply to bugs

What is actually broken. The sales director asking is not the problem; the route is. A request is being converted into work by one Developer under time pressure, which bypasses the Developers' ownership of the Sprint Backlog and hides the cost of the new work from everyone.

Framework facts that apply. The Sprint Backlog is a plan by and for the Developers; only the Developers change it during the Sprint. Scope may be clarified and renegotiated with the Product Owner as more is learned - so a swap is legitimate, but it is the Developers' call in conversation with the PO, and work of comparable size comes out.

What to do now.

1. The PO logs the discount-code request as a Product Backlog item. It is real demand; it should be visible and ordered, not absorbed.
2. PO and Developers check the Sprint Goal: if the new work does not threaten it and the team genuinely has capacity, they renegotiate explicitly - removing an equivalent item and updating the Sprint Backlog visibly.
3. Raise in the retrospective why the request arrived ad hoc. The likely answer is that the Sprint Review shows slides, so stakeholders have no working channel to influence the product and no confidence that it responds.

What not to do. Refuse the stakeholder without fixing the feedback channel, or let inserted work appear free. Both make the next insertion easier.

Diagnosis. A 14-slide status deck is a report about work, not an inspection of an outcome. The Sprint Review exists so the Scrum Team and stakeholders inspect the result of the Sprint and adapt the Product Backlog. Slides remove the only evidence that matters and shift the conversation to narrative and optimism.

Symptoms in the setup that confirm it. Stakeholders route requests by email mid-Sprint - a classic sign that the Review is not perceived as a place where influence works. Nobody has seen the increment, so the increment cannot generate feedback.

Replacement.

• Demonstrate the increment against the Definition of Done, on a real environment, with real data. No slides unless they frame a decision.
• Discuss progress toward the Product Goal, what changed in the market or in usage, and what is now the most valuable next step.
• Use the remaining time to reorder and refine Product Backlog items with the stakeholders present - that is the adaptation output of the event.
• Explicitly invite the sales director and other frequent requesters. Their presence is the point.

Trade-off to manage. Demoing unfinished or embarrassing work feels risky, but a Review that hides reality simply relocates the risk into the market. The Scrum Master should coach the PO on facilitating rather than presenting.

Why the claim fails. The Definition of Done is a commitment the Scrum Team makes about the increment, not about item types. If a Product Backlog item does not meet the DoD, it cannot be released or presented at the Sprint Review; it returns to the Product Backlog. Allowing a category of work to opt out creates exactly the situation here: untested changes in production, and two different meanings of "done" in one Sprint - which destroys transparency and makes the Sprint Review unreliable.

The legitimate version of the Developer's concern. Bug fixes are sometimes urgent, and full DoD (e.g., a lengthy review or documentation step) may slow a hotfix. That is a conversation about the content of the DoD, not about exempting work from it.

How to resolve it.

1. In the retrospective, make the two shipped fixes visible: what did skipping the automated test buy, and what did it cost or risk?
2. Re-examine the DoD as a team. If an element is genuinely unattainable for every item, renegotiate the DoD formally - do not carve out silent exceptions.
3. If speed of hotfixing is a real need, define an explicit, agreed path (shorter DoD with a tracked follow-up item) so the exception is visible in the Product Backlog, not hidden in a Sprint.

What the Scrum Master should avoid. Adjudicating as referee. The team owns the DoD and must own the fix.