A robotics company's Developers decide, on their own, that they no longer need to run the automated firmware regression suite before calling firmware work "Done," since it slows them down. Is this a valid use of self-management?
Select an answer to reveal the explanation.
Short Explanation
Self-management is about the how, not the what counts as finished. The Developers get to choose their own path up the mountain, but they don't get to move the summit — the Definition of Done is the team's shared, binding line for quality, and skipping it just hides risk instead of removing it.
Full Explanation
Self-management describes the Developers' internal decisions — who works on what, which technique to use, how to sequence the work — inside the boundaries the Scrum Team has agreed to. The Definition of Done is one of those boundaries: once the Scrum Team commits to it, dropping a step like regression testing to move faster isn't reorganizing work, it's redefining what "Done" means without going through the process that made it a shared commitment in the first place. The first wrong option collapses that distinction, treating any technical practice as fair game for unilateral change. The second is wrong because Definition of Done changes aren't a Scrum Master approval matter — the Guide doesn't grant the Scrum Master veto power over the team's technical agreements. The third misassigns ownership: the whole Scrum Team, not the Product Owner alone, owns and can evolve the Definition of Done together. A practical check for a Scrum Master: when a team proposes changing what "Done" means, ask whether that change is being made openly with the whole Scrum Team and reflected in the shared Definition of Done, or quietly by a subset of Developers under time pressure.