Chapter 11
Know What "Done" Means

What does “done” mean to your project? Here are some possibilities:

• The project met its date or scope commitments (or, if you’re lucky, both), and there aren’t too many problems, so the organization ships the product. The project is done.

• The project met its release criteria. The project is done and the organization ships the product.

• The project team is done. Someone else or another team packages the product in some way and releases the product later.

You might be accustomed to some rituals many nonagile projects use, such as “defect triage,” to decide on showstoppers. Or product managers or some other managers took a day and played the rapid-descoping-of-“mandatory”-requirements game because of the time. Or, one of my favorites, someone played the defect-promotion/demotion game at the end of the project. All of these games helped us feel better about the work, even if we didn’t make the work perfect.

With nonagile approaches, sometimes either a product manager or a senior manager will see a demo only the week before the project is supposed to end. That person may not like the way a feature works or looks. Or the team has so many defects, the managers say they can’t release. The project goes on and on and on….

Agile approaches provide us much more flexibility with seeing value and releasing over the course of the project. I already talked about release criteria as being the definition of “done” for the project. (See ​Develop the Release Criteria​.) But how does a team know the features are done? How does a team know that the interim value is ready for the customers to see and use?

Teams need to know what “done” means at the release level, for a feature set, and for a given story. That way, the team can always work toward being done at every level.

In this chapter, I’ll talk about the different levels of what done might mean for your team. I’ll also discuss the problems when your team is not the final stop before the customer can see the finished work.