What is undone work in Scrum, and how would you detect it accumulating across Sprints?

Every Scrum Team draws a line between work that is finished and work that is not. **Undone work** is the term teams use for what ends up on the wrong side of that line while the item itself has already been counted as finished: an item whose behaviour works but which was never reviewed, never verified by the checks the team agreed, never made observable, never deployed anywhere shared. The work has not vanished. It has moved from a place where it was planned into a place where nobody is looking. ## Why it is worse than work not yet started Work you have not started is honest. It sits in the Product Backlog, ordered against everything else, and anyone deciding a date can see it. A remainder hidden inside finished items has none of those properties: - **It is not counted.** The item carrying it is already marked finished, so the remainder appears in no plan. - **It inflates progress.** The number of finished items rises at the normal rate while releasable output rises more slowly, and the gap between them is invisible. - **It compounds.** Each Sprint adds a new remainder on top of the last, and the layers interact: unreviewed code is harder to review three Sprints later, and an unverified change now sits under six later changes that assumed it worked. - **It surfaces at the worst moment.** The bill arrives when somebody tries to release, which is usually the point at which there is least time to pay it. ## A worked example A public-library catalogue team keeps a 31-line Definition of Done — long, aspirational and written in one sitting. An audit of the 24 items marked finished across the previous three Sprints checks each item against each line rather than asking the developers. Seventeen of the 24 have at least one line unmet. Two lines account for most of it: accessibility verification is missing on 13 items and operational visibility on 11. Nobody decided to skip them. The list is too long to hold in mind, and neither of those two lines has any automation behind it, so both lose every time an afternoon runs short. That result is far more useful than a status report, because it points at the standard and the support around it rather than at individuals. ## How to detect it 1. **Audit finished items directly.** Sample items already marked finished and check them line by line yourself. Never ask whether the standard was met — asking measures memory and optimism. 2. **Listen for the vocabulary.** *Finished apart from*, *functionally complete*, *just needs the checks* are the standard being renegotiated one item at a time. 3. **Notice a proposed stabilisation period.** A block of time set aside to make finished work releasable is an admission that it was not releasable. 4. **Track which lines are skipped, not who skips them.** A line skipped by nearly everyone is a defect in the line — unrealistic, ambiguous, or unsupported by tooling. 5. **Compare the finished count with what actually reached users.** A widening gap over several Sprints is the clearest external signal available. | Symptom | Usual cause | |---|---| | Defects arriving from work finished several Sprints ago | Verification lines skipped under time pressure | | A stabilisation period proposed before every release | The standard has not been holding for a long time | | The same two lines missing across an audit | Those lines are unsupported or unrealistic, not neglected | | Items reopened days after being accepted | Behaviour was checked, the standard was not | ## What to do once you find it Make the remainder visible before anything else: it becomes ordered, sized work competing openly with new features rather than an intention somebody holds. Then treat the cause rather than the symptom. - If the standard is **too long to hold**, shorten it deliberately to what the team will meet every time, and say publicly that it was shortened. A smaller honest standard beats a large fiction, because only the honest one still means something. - If particular lines are skipped because they are **manual and slow**, the fix is investment that makes them cheap, not exhortation. A line nobody can afford will be skipped however often it is mentioned. - **Stop the inflow.** An item that does not meet the standard is not counted as finished this Sprint, however close it is, because the alternative is another remainder next Sprint on top of the one you just found. This is also the clearest argument for putting quality activity **inside** the standard rather than trusting it to intent. An activity in the standard is done by default and skipping it is a visible decision that somebody has to make; the same activity left to good intentions is the first thing dropped when a date approaches, and its absence leaves no trace. The judgement an interviewer is listening for is that undone work is a **measurement** problem before it is a quality problem. The quality gap is real, but the reason it grows unchecked is that the team's own reporting says it does not exist.