The answer to this question may sink your career, your team and your project. If you respond with a "yes," you may be forced to take on additional work. If you say "no," you may be branded as someone who can't get things done.
This innocent question is asked countless times on almost every software project. The way we answer, however, is anything but innocuous. If team members’ answers vary, it can degrade stakeholders’ trust in the project team.
Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of refactoring, process-thrash, unclear communication, and hidden work.
In this article, I describe the definition of done, how it adds value, and the value it communicates to stakeholders. Then, I present an exercise that will help you build your own definition of done definition of done and manage it over time.
The Story
I once was hosting a story workshop, the precursor to a kickoff meeting for a large, back-office infrastructure project. There were roughly twenty stakeholders in the room: systems engineers, general managers, developers, marketing people, product managers and salespeople. I knew from the beginning that such a diverse group would be a challenge and that I would need to focus the meeting in order to filter out the noise and get the real requirements needed to start the work.
Prior to the meeting, the team and I had met to create our definition of done. Though I had the definition of done with me, I chose not to share it at the beginning of the meeting. I did this for two reasons: I wanted to ensure people felt open and unconstrained by a predetermined definition and I did not want them to get the impression that the definition of done was up for negotiation.
Two hours into the meeting, we had identified approximately 200 stories. This was a huge success; however, people were starting to get hung up on the order in which the stories would be accomplished. Naturally, the systems engineer wanted to see monitoring, security, and all hardware and network infrastructure built out. The marketing people just wanted a release date. The developers and testers wanted to drill into the weeds to figure out what each story meant.
It was at this point that I revealed the definition of done as identified by the team. The definition of done covered what it meant to be done with a story, a sprint, a release to our integration environments and, last but not least, our release to production environment.
