Mike Lyons explains the definition of done, a team checklist that makes finished explicit and prevents half-done work. It scales across release levels from prototype to full release, and starts with three questions about what your team actually needs before calling something complete.
A half finished product. It's worse than no product at all. Just ask anyone who's lived through a kitchen remodel that drags on for months and months. Well, back in the early 2000s, software teams kept running into the same problem. Everyone had a different idea of what finished looked like. I hate to be the one to break it to you, sweetheart, but you are not done. The creators of Scrum, they solved this by introducing a simple tool called the definition of done. That's not a fancy thing, it's just being clear about what finished means. The definition of done is a simple checklist that lists everything needed to make something complete. It's like having a standard completion checklist for every part of the kitchen remodel. No matter who does what work, all of these things must be done. For taskflow, we might release a new feature for tracking billable hours. Let's say the developers, they say it's done. And let's say the testers, they say it's done too. But when they say done, they didn't include automated tests or documentation. Six months later, when we need to update the feature, the team has no tests to ensure that it won't break existing functionality. And the new developers, they have no documentation to understand how it works. If we don't have a clear definition of done, these crucial elements, they often get skipped. Now, something I want to point out here is that definition of done. It's different than acceptance criteria. Think of that kitchen remodel we were talking about a minute ago. Acceptance criteria would be install white marble countertops. But definition of done includes things like all electrical work inspected, plumbing tested, for leaks, debris removed, and surfaces cleaned. See these things? They apply whether you're installing white marble countertops or building cabinets or putting in a new floor. Something interesting to point out here is that definition of done adjusts based on the type of work you're doing. Let's look at different levels, from experimental to production ready for prototypes and proof of concepts. Done might be as simple as core functionality works, basic testing complete, and we're demo ready. But for MVPs and beta releases, the bar gets higher. Core features tested, basically, basic documentation ready, known, limitations documented, and feedback collection mechanisms are ready for production. Features done might mean code reviewed and checked in all tests, passing cross browser verified, tech docs updated, security scan complete, and help guides updated. And then for full releases, wool definition of done includes even more. All features tested, performance verified, release notes ready, support team trained, backup confirmed, and rollback plans tested. See, each level builds on the previous one. Adding more rigor as the stakes get higher. Just like how the kitchen remodel needs both rough inspections and final inspections. Now, just a pro tip here. To get started, you could simply ask three questions. What do developers need to complete? What do testers need to verify? And what do users need to succeed? This could be your first cut at a checklist. And to validate if these are the right things, you could simply ask, what if we skipped this step? If the answer is that problems will occur, you've probably got a good definition of done criteria. Skip load testing. Well, the system could crash during peak usage. Skip accessibility testing. Well, you could be shutting out thousands of potential users. Skip proper error logging. You spend hours trying to reproduce bugs and find fixes. What I like about this question, like what happens if we skipped? It demonstrates the importance of not skipping definitions of done. Teams that skip definitions of done, they end up paying a heavy price down the road. The cost of doing it right the first time, it's always less than the cost of fixing it later. Look, I get that creating a definition of done, it takes time upfront, but here's what I've noticed over time. Having a clear definition of done, it actually saves time. It saves time mainly by preventing half finished work from piling up. When teams know exactly what done means, they complete each piece fully before moving to the next. But even then, sometimes getting your team to embrace a definition of done, well, it takes more than just creating a list. Start by involving everyone in creating it. Developers, testers, support staff, everyone. When people help create the standards, they're more likely to follow them and make it visible. Put it on your wall or put it up in your collaborative workspace wherever your work happens. And then celebrate when teams meet all the criteria, that just builds good habits. Now, when someone asks to skip a step, it's a great time to review the list. You might share stories of past problems that came from skipping steps. And you also need to be ready to remove items that no longer add value. I gave you some questions you could ask to get started. But keep in mind your definition of done needs to evolve. As the company grows and markets change and your user base evolves, you'll likely need to add or remove items. It's like how kitchen requirements change. Today's homes need more electrical outlets than kitchens from the 1990s, for example. So there you have it. The definition of done. It's not about making things perfect. It's about being clear what finished means for your team and for your customers.
