Definition of Dumb

Image by David Cardinez from Pixabay

Scrum's Definition of Done (DoD) is a convenient way for Scrum advocates to punt on resolving any real issues with their process.

If anyone complains that Scrum produces poor results, they have their ready response: The DoD should prevent this; if the work doesn't fit the DoD, it should be rejected; developers are simply not following the process.

Despite the inefficiencies and frustrations Scrum piles on developers, poor results are "impossible." Why? Because the Scrum Master has defined them away—binding programmers to their unholy oath of compliance.¹

In their world, poor results don’t exist.

They can’t exist. The DoD forbids it.

These are not the droids you’re looking for.

The Scrum Guide defines the Definition of Done as a shared understanding of what it means for a product increment to be complete—a quality standard ensuring all increments are potentially shippable or releasable. In other words, “nothing ships unless it’s perfect.” Easier said than done.

Here are some common items for a DoD:

• tested

• documented

• reviewed

• no bugs

Good ideas, but unless your process builds them into daily workflows—through TDD, pair programming, or literate programming—they’re just bolt-ons, band-aids to stop the bleeding.

This thinking leads to an ever-growing checklist of ways to reject work: pre-authorizations, design approvals, 100% test coverage, team-wide code reviews, and tedious manual testing phases straight out of the Waterfall era.

An ever-growing bureaucracy. Pure quality theater.

To their credit, they named the DoD well. That’s exactly what it is: a definition—not a solution, not a root cause analysis—just a description of what quality software should look like. Once it's drafted, the team is expected—by decree—to produce only quality output. Nothing else is acceptable. Take what Scrum gave you before, don't change anything about the process, but now get different, higher-quality results. It's closer to the definition of insanity.

It’s a lot like running an apple orchard and claiming your process only produces flawless fruit: no bruises, perfect color, uniform sweetness. But the truth? The orchard just tosses every imperfect apple in the dumpster before they reach the market. Perfect apples at the market say nothing about the process. For all you know, they’re wildly inconsistent at growing good fruit—throwing away nine (or ninety-nine) apples for every one they keep.

What's worse is that corporations that run Scrum do not modify delivery expectations to account for process inefficiency, because they don't believe they exist. They shut their eyes to it. Yet they still demand a hundred apples a day. "Come on, what's so hard about picking a hundred apples a day?" What they don't see, however, (what they don't want to see) are the nine hundred apples that go into the dumpster in the back, while their workers hunt for a hundred apples that meet their criteria.

This way, developers end up doing the extra legwork themselves, if they want to get a reasonable product out of the frustratingly difficult practices of Scrum. Maybe you've heard this before? "If you can't meet your sprint commitments, you're expected to do nights and weekends."

That’s why I call the Definition of Done a punt—a way to dodge fixing real process deficiencies. It shifts all the responsibility for inefficiency to developers and hands them all the blame as well. Because, anyone who questions the system must be a malcontent that doesn’t do Scrum correctly—not someone with valid concerns.

Sooner or later, frustration and exhaustion take their toll. Companies end up with sprints yielding only a couple hundred apples total to choose from. So, definition or no definition, they’re stuck with whatever the system produces—even if only a few features can be considered “good” at all. Developers face a Sophie’s Choice: deliver subpar features or nothing at all.

This is the point when turnover ramps up, fingers start pointing, and scapegoats are born. Wise companies will eventually fire the management responsible for running productivity into the ground, but usually not until a lot of well-meaning developers go down in flames—and long after anyone good has headed for the hills.

It's a sad story I have lived through many times. But the solution is not hard. Ditch the rigid Scrum regimes still ruling the industry and hand control of the engineering process back to the engineers. And I'm not talking about giving control to engineering managers who toe the company line and are just as invested in Scrum as the business. Give control to the engineering team--the developers writing the code--the ones opening up their IDEs, typing in the code, and hitting compile.

Let them organize themselves. They’re the ones who know how to craft the right process for their work—one that naturally delivers better results. Do that, and the Definition of Done won’t matter anymore. The system will simply produce high-quality fruit on its own.

#endscrumin2025

1. The way this plays out is subtler in practice. The Scrum Master often frames the Definition of Done as the developers' own idea. They sit the team down and ask reasonable questions like, “What steps can we take to ensure high quality?” Once the answers are written down, they become the club used to beat you over the head.