Your Definition of Done Is Wrong

Matt Watson, CEO of Full Scale and 4x founder, argues that the standard definition of done in software development is dangerously incomplete because it treats code shipping as the finish line instead of confirming customer value. Watson cites Pendo research showing 80% of features are rarely or never used, and contends that with AI writing much of the code, the real work is deciding what to build and proving it mattered.

Your Definition of Done Is Wrong. Matt Watson /authors/matt-watson/ · CEO of Full Scale, 4x Founder, Author of Product Driven In this article QUICK ANSWERThe standard definition of done says work is finished when the code meets your team’s quality bar and ships. That definition is wrong, or at least dangerously incomplete. Done isn’t when the code ships. It’s when the customer’s problem is actually solved and you’ve confirmed it. And now that AI writes much of the code, the finish line has moved: the real work is deciding what to build and proving it mattered. Ask a Scrum team what “done” means and you’ll get a clean answer. The Scrum Guide https://www.scrum.org/resources/what-definition-done calls the definition of done “a formal description of the state of the Increment when it meets the quality measures required for the product.” Reviewed, tested, merged, deployable. Check the boxes and you’re done. I’ve shipped software for more than 20 years, and I think that definition is quietly wrecking products. Done isn’t when the code ships. It’s when the customer sees value. The standard definition of done draws the finish line at the exact moment the engineer stops being useful and the customer still has nothing. Everything that determines whether the work mattered happens on the other side of that line, and the way most teams define “done” tells everyone to walk away right before it. What the definition of done actually says today To be fair to the idea, a definition of done does real work. It’s a shared checklist a team agrees on so that “done” means the same thing to everyone, instead of one engineer’s “done” being another’s “barely started.” A typical definition of done looks like this: - Code is written and peer reviewed - Unit and integration tests pass - The feature meets its acceptance criteria - Documentation is updated - It’s merged and deployed to production That’s useful. A team with no shared definition of done ships inconsistent junk, and people waste half their week arguing about whether a ticket is finished. I’m not against having one. People mix up the definition of done with acceptance criteria, so it’s worth being precise. They are not the same thing. | Definition of done | Acceptance criteria | |---|---| | Applies to every work item on the team | Specific to one story or feature | | Quality bar: tested, reviewed, deployable | Behavior: does this story do what was asked | | Set once by the team, rarely changes | Written fresh for each story | | “Is it built to our standard?” | “Did we build the right thing?” | Atlassian and most agile coaches https://www.atlassian.com/agile/project-management/definition-of-done draw the same distinction. Acceptance criteria tell you the story did what the ticket said. The definition of done tells you the increment is built to standard. Here’s the problem. Both of them stop at the same place. Both of them treat “done” as a property of the code. Neither one asks the only question that actually matters. “Code shipped” is the wrong finish line Did it work? That’s the question the standard definition never forces anyone to ask. Did the customer’s problem actually go away, and did anyone check? For most teams, the honest answer is no, because the process gives them no reason to. The sprint ends, the ticket moves to Done, the next sprint starts, and there is no time built in to see whether the thing you shipped helped a single human being. So you get the result the whole industry quietly lives with. Pendo studied feature usage across hundreds of products https://www.pendo.io/resources/the-2019-feature-adoption-report/ and found that 80% of features are rarely or never used. Most of what your team marks “done” is code that no customer ever touches. Think about what that means. The majority of the work an engineering org ships, work that passed code review, passed tests, met its acceptance criteria, and was correctly marked done, delivered nothing. By the standard definition of done, all of it succeeded. That’s not a quality problem. Your tests passed. That’s a definition problem. When you ship without follow-through, you don’t just waste the effort. You accumulate product debt. Every unused feature is more code to maintain, more surface area for bugs, more weight the product carries forever. You can carry that the same way you carry technical debt https://fullscale.io/blog/cost-of-technical-debt/ , except it’s worse, because technical debt at least supports something a customer uses. I lived this at VinSolutions, the auto-dealer software company I co-founded and later sold. We built features for car dealers that we were proud of and that, when I actually looked at the usage data, dealers never opened. We had shipped them. We had marked them done. The dealer’s problem was sitting right there, untouched, because nobody on the team owned the gap between “we deployed it” and “it changed something for the customer.” The definition of done told us to stop the moment the code went out. That gap is where products are won and lost, and most teams have defined themselves out of it. The old definition of done built an assembly line There’s a reason none of this has ever really worked, and it isn’t a people problem. It’s structural. The way we built software teams turned them into an assembly line. A typical feature passes through a row of stations: - A project manager schedules it - A product owner writes the ticket - A front-end developer builds the screen - A back-end developer builds the logic - An API person wires it together - A QA person tests it Each person does their small part and passes the ball to the next station. And on an assembly line, your job is to do your piece and hand it off, so that is exactly what everyone’s definition of done became. The product owner’s done is “I wrote the ticket.” The back-end dev’s done is “the API works, I handed it to the front end.” QA’s done is “it passed my tests, I moved it along.” Everybody on the line hit their own definition of done. The product still failed. Nobody on the line was responsible for whether any of it mattered. That’s the real problem with the old definition of done. When you split the work into stations, you also split the ownership into pieces so small that no one is left holding the big picture. Each person becomes an order taker doing their part, a cog in the machine, and the only output anyone actually measures is movement: did the work get to the next station. Whether the customer’s problem got solved was never anyone’s line on the board. This is also why no amount of process ever fixes it. You can’t fix broken engineering with more process. More handoffs, more ceremonies, more sign-off gates just make the assembly line longer. The thing that’s broken is that the line exists at all. The teams that ship products that matter don’t run an assembly line. They tear the stations down and put product, design, and engineering in the same room https://fullscale.io/blog/cross-functional-collaboration-development-product-design/ , where the people building the thing also understand the problem and care how it lands. On those teams, everyone owns the product https://fullscale.io/product-driven/everyone-is-the-product-team/ , not a station on the line, and “done” can finally mean something bigger than “I did my part.” Real done is when the customer succeeds In my book, Product Driven https://fullscale.io/product-driven/ , I spend a whole chapter on this, because it’s the single mindset shift that turns coders into product engineers. The fix is to expand what you call “start” and what you call “done.” Here’s how I put it in the book: “‘Start’ when the ticket arrives. ‘Done’ when the code ships. But that’s not ownership. That’s task completion.” Start doesn’t begin when the ticket lands in someone’s queue. It starts when your team sees a problem worth solving, which means engineers have to be close enough to the customer to see it. And done doesn’t end at deploy. It ends when the user can succeed with what you built and you’ve confirmed they did. When you redefine “done” as a solved problem, everything changes. The work that was always invisible suddenly becomes the job. Reading the support tickets. Watching a session recording of someone fumbling through the feature. Sitting in on a customer call. Checking the dashboard a week later to see if the fix actually moved anything. I call this the hidden work, and it falls on whoever cares most, which is how it lands on a leader’s plate. Picture the typical org. The CTO is reading support tickets at night because she’s the only one who connects them back to the roadmap. The engineering manager sits in every customer call because nobody else does. The tech lead quietly checks whether last month’s fix worked. All of that context is trapped in two or three people who can’t possibly scale it. This isn’t about hiring better people. The team’s definition of done ends before the hidden work begins, so the hidden work never gets owned by the people doing the building. Engineers who think like owners https://fullscale.io/blog/lessons-learned-in-scaling-engineering-teams/ close that gap themselves. Engineers who wait for tickets can’t, because their definition of done told them the job ended at the merge. I wrote the full version of this argument as a standalone chapter, redefining start and done https://fullscale.io/product-driven/redefining-start-and-done/ , if you want the long form. You can’t fix this with more process. Adding a “post-launch review” ceremony to your sprint doesn’t help if the team still believes done means deployed. The belief is the thing that has to change. If all of this sounds like “outcomes over outputs,” that’s because it is. The idea isn’t new. Marty Cagan https://www.svpg.com/ has spent years pointing out that most teams still ship feature roadmaps instead of outcome roadmaps, and lean product people have made the same case for just as long. I’m not claiming to have invented it. So why hasn’t it stuck? For twenty years this was a philosophy. A nice idea you could nod along to and then ignore, because the code still had to get written either way, and writing it was most of the job. That’s the part that just changed. AI just made the old definition of done worthless Here’s why this matters more in 2026 than it did when I started writing about it. If “done” means the code is checked in, then AI is already done with everything. AI now writes much of the new code https://fullscale.io/blog/impact-ai-software-development/ on most teams. Google’s CEO said 75% of the company’s new code is now AI-generated https://www.semafor.com/article/04/24/2026/google-ceo-says-75-of-companys-new-code-is-ai-generated , up from 25% two years earlier, and that the work has turned agentic: engineers supervise the AI instead of typing the lines themselves. Across the industry, 84% of developers now use or plan to use AI tools https://survey.stackoverflow.co/2025/ai/ . The typing, the boilerplate, the glue between systems, the part the old definition of done was secretly measuring, is the part being automated fastest. If your finish line is “the code exists and it’s merged,” you’ve defined the job as the one thing machines are now best at. That definition was always incomplete. AI just made it useless. Pure coders will be replaced by AI. Problem solvers will run technology organizations. When code is cheap to produce, the value moves entirely to the two ends the standard definition of done ignored. Deciding what to build, and verifying it mattered. The real developer shortage https://fullscale.io/blog/developer-shortage/ isn’t a shortage of people who can write code. It’s a shortage of engineers who can own that whole arc. The hard part of software development was never writing the code. It’s understanding the problem you’re trying to solve, and that’s the half of the work AI can’t do for you. So the new definition of done is the opposite of the old one. Done isn’t “we wrote the code.” A machine can do that in seconds. Done is “we figured out the right thing to build, we shipped it, we confirmed it delivered value, and we learned something from how the customer used it.” That arc is the job now. The code in the middle is the easy part. Cheap code isn’t the same as correct code. Veracode found that 45% of AI-generated code carried a known security flaw https://www.veracode.com/blog/genai-code-security-report/ , and the bigger models didn’t fix it. When a machine can produce plausible code in seconds, confirming the thing actually works and actually helped is the part that needs a human most. The verification half of “done” matters more now, not less. This is also why hiring the cheapest possible developer is a worse bet than ever. If you hire for typing speed, you’re paying for the commodity. The trap of buying engineering on price alone https://fullscale.io/blog/cheapshoring/ , what I call cheapshoring, gets more expensive every year that AI gets better, because you’re optimizing for the skill that’s disappearing instead of the judgment that’s becoming everything. How to redefine done on your team You don’t change a definition of done with a memo. You change it by changing what the team is responsible for and what you reward. A few things that actually move it: - Expand the boundaries on paper. Rewrite your definition of done so the last line isn’t “deployed to production.” Make it “confirmed the customer outcome we intended.” Keep every quality check you already have. You’re not lowering the bar, you’re adding the part that was missing. If you can’t confirm the outcome, the work isn’t done, it’s shipped. Those are different words for a reason. - Put engineers near the customer. They can’t own an outcome they never see. Get them into support tickets, customer calls, and usage data. If your engineers genuinely can’t reach end users, because you’re in a regulated space, a deep platform team, or agency work, give them the next best proxy: the usage data, the support queue, and a product manager who carries the customer’s voice into the room. The moment an engineer watches a real user struggle, the definition of done changes itself. - Build follow-through into the schedule. Leave room after a launch to check whether it worked. This only works once the team believes done means solved, so add the time after the belief changes, not instead of it. A feature that nobody validates is a coin flip you chose not to look at. - Reward outcomes, not output. As long as you celebrate “shipped 40 tickets this sprint,” you’re paying people to hit the old definition of done. Celebrate the fix that dropped support volume, or the feature that moved a real number. - Staff for ownership, not just throughput. This is the hard one, and it’s why the engagement model matters. Staff augmentation done right https://fullscale.io/staff-augmentation-services/ means embedding engineers who own the problem alongside your team, not a vendor you toss a spec to and hope. When we build long-term teams for clients https://fullscale.io/blog/what-is-staff-augmentation/ , the whole point is that the engineers care about the product the same way your in-house people do. That’s the only kind of team that can hold the expanded definition of done, because the expanded definition is really just ownership with a clearer name. None of this requires a new framework. It requires deciding that “done” means the customer succeeded, and then building the team and the process around that one sentence. Frequently asked questions What is the definition of done in agile? In agile and Scrum, the definition of done is a shared checklist a team agrees on so that every work item meets the same quality bar before it’s called complete: reviewed, tested, documented, and deployable. It’s a commitment about the quality of the increment, set once by the team and applied to all work. What is the difference between the definition of done and acceptance criteria? Acceptance criteria are specific to one story and describe what that feature must do. The definition of done applies to every item on the team and describes the quality standard it must meet. Acceptance criteria ask “did we build the right thing?” The definition of done asks “did we build it to our standard?” Neither, by default, asks whether the customer’s problem was actually solved. Who creates the definition of done? The whole team owns it, not one person. Developers, QA, the product owner, and anyone else accountable for quality agree on it together and revisit it as the product and team change. A definition of done handed down by one manager rarely sticks. Does AI change the definition of done? Yes, more than anything else has. When AI writes much of the code, “the code is finished” stops being a meaningful finish line, because the code is the part that’s now fastest to produce. The valuable work shifts to deciding what to build and confirming it delivered value, which means a modern definition of done has to extend past deploy to the customer outcome. What’s a better definition of done? Done is when the customer’s problem is solved and you’ve verified it, not when the code ships. The code passing tests and merging is necessary but not sufficient. A strong definition of done adds the outcome: the user can succeed with what you built, and someone checked that they did. Most teams will read this and keep their old definition of done anyway, because the old one is comfortable and it lets everyone go home when the code merges. The ones that change it will build products people actually use. That’s the entire game now, and it’s getting more true every month. If you want the full argument, it’s the spine of my book, Product Driven https://fullscale.io/product-driven/ . And if you’re trying to build a team that can actually own outcomes instead of just closing tickets, that’s the kind of engineer we help companies hire https://fullscale.io/hire-developers-philippines/ .