With a retail launch date only one Sprint away, the Product Owner suggests the Scrum Team declare this Sprint's device-pairing feature Done even though it still fails the pairing-reliability tests specified in the Definition of Done, reasoning that the date matters more this one time, so how should the Scrum Master respond?

The Definition of Done represents a quality standard the whole Scrum Team has agreed to, and it is not meant to flex under the pressure of any single Sprint, however important that Sprint's deadline feels. The Product Owner's accountability for maximizing value does not extend to unilaterally waiving the team's quality standard, because doing so hides real risk rather than managing it — a pairing feature that fails reliability tests can create serious support and reputation problems once it reaches real households. The Scrum Master's role is to protect the integrity of that standard while helping the team see its actual options clearly: ship the release without this feature, delay the release, or accept the risk explicitly and transparently if leadership decides to override normal process outside of Scrum. Quietly excluding the item from the real release while reporting it as Done manufactures a false signal that will eventually surface as a support or safety issue instead of an honest planning conversation now. Asking Developers to grind through unpaid overtime treats a systemic pressure problem as an individual sacrifice, and it does not by itself make an unreliable feature actually reliable. A useful check is to ask whether the team would accept this same shortcut in a Sprint with no external deadline at all — if not, the deadline is distorting the standard rather than being managed around it.