A firmware Developer finishes the code for a new obstacle-avoidance routine, but the automated sensor-calibration tests that the Definition of Done requires have not been run against a physical unit by the end of the Sprint, so what should happen to that Product Backlog item?
Select an answer to reveal the explanation.
Short Explanation
Think of the Definition of Done like a doorway: work either walks all the way through or it doesn't count as having arrived. If the calibration tests haven't run, the routine hasn't cleared the doorway, so it can't be called part of the Increment. It just goes back on the Product Backlog, unfinished, to be picked up again.
Full Explanation
A Product Backlog item that does not meet every criterion in the Definition of Done is, by definition, not part of the Increment, no matter how much effort went into it or how close it looks to finished. That item returns to the Product Backlog, where the Product Owner can re-order or re-scope it for a future Sprint. This is not a punishment; it protects the meaning of "Done" so that everyone — the team, the Product Owner, and stakeholders — can trust that anything called an Increment is genuinely usable. Treating near-complete work as Done because it took real effort confuses activity with delivered value, and eventually erodes stakeholders' confidence in what "finished" means. It also hides risk: an obstacle-avoidance routine that hasn't been calibrated against real hardware could behave unpredictably once it reaches a physical robot, which is exactly the kind of problem the Definition of Done exists to catch before release. A useful operational check is simple: walk the item against every line of the Definition of Done, one by one, and if any line is unmet, the item is incomplete — full stop, regardless of how many lines did pass.