The question is a cliche among agile teams: what does Done mean? I recently heard a number of responses from two teams:
- It works so well we are willing to give it to the customer. I like this definition. These team members are proud of their work and are focused on pleasing the customer.
- The pilot has landed the airplane safely. The metaphor is that we are delivering a service, a trip on an airplane. It is an attractive metaphor because of the extremeness of the Not Done case: the plane crashes and people die. The metaphor becomes squirrelly, though. Is it Done if the entertainment video screens were broken? Is it Done if there were no snacks and drinks on the flight? The team agrees that this metaphor doesn’t work.
- The code compiles, you can install the app, you can launch the app, and you can exit the app, but there are many bugs left to fix.This team member decomposes the realization of a story into Code, Test, and Debug; he is thinking Waterfall rather than Agile. He focuses on the Code segment, and thinks he is Done when he is done with the initial coding. He is working in isolation, not well integrated with the team. He misses the point that the story is not Done until the team decides it is Done.
- The app is ready for production deployment. This is another good definition, similar to the first one. This team member is focused on the customer and end users. The team is not Done until it can publish the app on production servers and share it with the world.
Done is an important concept. When we plan sprints and releases, we estimate stories and tasks in terms of how long it will take for the team to be Done. Discussing and defining Done is a valuable exercise and conversation.
