Are you done yet? The Agile Definition of Done

Daily during the lunch break as I stand from my bay heading towards the canteen, I see a poster in the next project bay saying ‘Definition of Done’. “Need to post an article about this” I think daily. Finally today is the D-day. Definition of done is one of the Agile fundamental things. Yet many teams do not see its importance or are unsure what Definition of Done actually is. The term is also often confused with the acceptance criteria, leading to mis-communications and false expectations. So, let’s have a look at this important agile concept – the definition of done.

Done, i.e. completed, finished or ended. Simple, right? Why do we need a separate definition for it? Why is it an important agile concept? Done means done, then why so much hunky-dory about it? What’s so difficult in it? Okay. Even if we define it somehow, what are the benefits? Is it worth the time? How to define ‘done’ in agile context? Who defines it? Hufff! So many questions in my mind. Let’s try and answer these one at a time.

The pre-DoD era

A software project has multiple teams, i.e. functional, architects, developers, testers, database experts, etc. Ask a specific team if the work is done? And here comes the reply,

  1. Yes, the functional design document is ready.
  2. Yes, based on the requirements we have shared the proposed design with the development team.
  3. Yes, we have completed the development & build is deployed for testing.
  4. Yeah! The testing is complete. We are just doing some regression tests.

Inquire further as to whether this is adequate for work to be of production quality, and the team can become defensive or sheepish. Now let’s change the question a little – ‘Can the work done be deployed to production now?’ and there you go. The answers change a little,

Nah! Some of the tasks are pending like code review, defect retesting, automation suite, audit, etc.

What do you think happened? Yeah! The definition of done is different for different teams and people. There is no single definition of done that can say ‘Yes, this requirement is done & can be delivered’.

“Are you done yet?”

Developers are not done by just writing the code. Peer-review should be completed. Code should be refactored as per design suggestions. Unit tests must be designed for all of the features in development. Requirements should be traced to the code implementation such as by clear feature-relevant naming conventions. The unit test cases should have been executed and the increment proven to work as expected.

Testers are not done by just verifying the requirements. All test cases should be executed. All outstanding defects (or incidents such as build issues) should be elicited and resolved. Automated Test suite should be in place. Regression tests should be completed and the functionality provided in previous iterations has been shown to still work. Test Report should be prepared. Performance, security, and user acceptance testing should have been done, and the product should be shown to work on all required platforms.

As a team – you are not done by just writing the code, executing the test cases, etc. For a requirement to be deployed in production environment – much more needs to be done. That’s where ‘Definition of Done’ comes into picture.

The Definition of Done

By 2007, Definition of Done has become widespread as a full-fledged practice, and as a textual checklist displayed in the team room. But what is it actually? Taking a cue from previous text,

“Definition of Done is a list of conditions that must be met to call something done, that is ready to be shipped to the customer.”

“Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations.”

It is a clear and concise list of requirements a software increment must adhere to in order to be considered a completed user story, sprint, or be considered ready for release. It is a comprehensive checklist of necessary activities that ensure that only truly done features are delivered, not only in terms of functionality but in terms of quality as well. Usually, this encompasses a lot of things from coding, documentation, testing to training, updating help pages and manuals and preparing the software for delivery. A Definition of Done drives the quality of work and is used to assess when a User Story has been completed. It may vary from one Scrum Team to another, but must be consistent within one team.

Different Levels of ‘Done’

Can we do this activity for each feature? If not, then

Can we do this activity for each sprint? If not, then

We have to do this activity for our release!

Yeah! We do have different levels of Done. It can be for a feature (story or product backlog item), a sprint (collection of features developed within a sprint), or for a release (potentially shippable state).


The story should have well defined acceptance criteria, working code, reviewed, unit tested, checked in to the source control system and the build should pass with all the automated tests running.

Sprint goals are defined, all stories developed have been accepted by the product owner, automated acceptance tests have passed and test report submitted.

Formal Release date is communicated, all stories for the release are completed and accepted, changes deployed to the test environment and passed, deployment guide is ready and training manual is prepared.


  • Only the done and accepted user story will contributed to the team velocity. Meet all of the defined criteria or the user story is not done.
  • After a story or sprint is done, Definition of Done is used as a checklist to verify whether all necessary value-added activities were completed.

Definition of Done | Sample criteria

Once you understand the meaning, the next obvious question that comes to mind is what all things to include in Definition of Done? Or what kind of action items are included in a definition of done? Don’t worry. Below we have compiled some of the common action items that agile teams include in their definition of done chart.

  • User experience guidelines must be followed.
  • Code produced (all ‘to do’ items in code completed)
  • Code commented, checked in and run against current version in source control
  • Peer reviewed (or produced with pair programming) and meeting development standards
  • Builds without errors
  • Unit tests written and passing
  • Deployed to system test environment and passed system tests
  • Passed UAT (User Acceptance Testing) and signed off as meeting requirements
  • Any build/deployment/configuration changes implemented/documented/communicated
  • Relevant documentation/diagrams produced and/or updated
  • Acceptance criteria met
  • Automated regression tests pass
  • Non-Functional requirements met
  • Meets compliance requirements
  • Functionality documented in necessary user documentation
  • Product Owner accepts the User Story

Note: This is just an example to give you an idea about what kind of activities are included in definition of done. It may vary from one Scrum Team to another, but must be consistent within one team.

Who is responsible for framing Definition of Done?

The Project Manager? Nah! The developers? Nah! Product Owner? Nah! Oh! The client right? Nah! None of them sets the definition of done for an agile team. Rather all of them. Everyone on the team, no matter what their expertise or background is, can add value and should be involved. The bottleneck?  We have been conditioned to work in our functional silos for so long that the answer leaves us perplexed. But not now. Every team member is a participant in the exercise to frame definition of done, that is then accepted by every team member. Keeping team members out of this exercise, though, only deprives the team of the valuable contributions of other team members. It also keeps them from having a valuable team building exercise. I recommend having the entire team do this exercise, regardless of skills, background or role on the team.

The Definition of Done is created by the team, but may require the Scrum Master to enforce quality constraints if the team don’t have clear development standards. For example, a team may not want code reviews or unit tests, but a Scrum Master may need to enforce them to ensure quality is maintained. In the ideal situation the team see the benefits and want such quality constraints, but the real world isn’t always ideal.

The process of creating Definition of Done

Okay. We know all team members will contribute to the definition of done. But how? How do you ‘create’ a definition of done for your agile team? The team getting into a meeting room should be a good start 😉


Kick-off the meeting with a brainstorming session to answer one of the basic question – “What do we need to do, as a team, to ship software to our customers/stakeholders?” It can be acceptance criteria, code written & reviewed, code commented, unit tests completed, functional tests done, defects closed, test report prepared, design followed, etc. The aim is to collect large quantities of ideas with no criticism.


Aha! The interesting part. Conditioned to work in functional groups, the most obvious categorization would be design, development, test & management. But wait a minute. Aren’t agile teams cross-functional? Unfortunately, categorizing this way reinforces our functional roles within a team and does not promote cross-functional interaction. It also tends to create a mini-waterfall for each iteration 🙂

Now let’s change the perspective. Instead of vendors, let’s wear the client shoes. What will you want as a client? Yeah! The requirements should be delivered in production. That’s it. Don’t tell me design is done, developers are coding, testing is in progress, or whatever. Just tell me if we are ready to go to production? The intermittent process doesn’t matter to me. Coming back to vendor-shoes 😉 the idea is to focus on customer value. Delivering stories at the end of an iteration and releasing to an integration environment where customers can use and interact with the software provides value. Even more value is provided if a system is released to a production environment and officially done. Keeping this in mind the categorization might include,

  • User Story done
  • Integration done
  • Release to SIT
  • Release to Production
  • Customer Training

Once the categories are identified, clear, and understood by the team – put all the ideas brainstormed into their respective categories.

Sorting and Consolidation

This is a simple team exercise. Verify all the items in different categories, discuss & refine the items like removing duplicates (exact matches, similar matches) or discussing on “we don’t know what the heck these are.” Items. Once refined, make sure team understands what each item means and is in the right category.

Create the Definition of Done

Creating and publishing the definition of done is the easiest part. The matrix prepared above is nothing but the Definition of Done. A perfect Definition of Done includes everything that the organization has to do to deliver the product to customers. Publish & circulate the matrix prepared. Publish the definition of done on the internal team website and create a poster that can be hung for all to see. It serves as a reminder of what it means for the team to be done and acts as a powerful communication tool.

Why we need a ‘Definition of Done’?

Why is “Done” so important? Well, incomplete work has a nasty habit of mounting up, and without visibility of how much effort truly remains, the deficit can quickly get out of hand. Establishing an upfront, common understanding of “done” can save teams and businesses countless hours of refactoring, process-thrash, unclear communication, and hidden work. The Definition of Done ensures everyone on the Team knows exactly what is expected of everything the Team delivers. It ensures transparency and quality fit for the purpose of the product and organization.

  • Better Decisions and Planning: work is planned to accommodate the agreed Definition of Done.
  • Knowing when you are “Done” frames the work which must be undertaken in order to get there.
  • Formally defining the meaning of ‘done’ reduces variability and the likelihood of undone work and measuring progress unambiguously (‘done’ or ‘not done’).
  • Transparency reigns. What has truly been delivered? Is the increment of demonstrable release quality, immediately usable, and of actual value to stakeholders?
  • Clear Communication: progress is easy to track and report. The remaining work to do is clear.
  • Help all the stakeholders visualize the team’s commitment to do the best possible work to meet the needs of the business and its customers.
  • Limits the cost of rework once a feature has been accepted as “done”.
  • Having an explicit contract limits the risk of misunderstanding and conflict between the team and the customer or product owner.
  • It helps build a bond between team members. It gives them the feeling that they are “all in this together” and that it is more important to deliver on their commitments than to focus on specific individual tasks.
  • Expectation Setting – common understanding among all developers, product owners and quality assurance. When we say a task is done, everyone on the team knows what that means.

When used correctly, it provides the team with a common vision on how to achieve the iteration, release and project goals. It’s a way of life – not a checklist to follow, but a commitment to excellence.

Definition of Done != Acceptance Criteria

Don’t confuse the Definition of Done with Acceptance criteria. They both have different perspectives. The Definition of Done focuses primarily on quality and processes — so that you do all the steps that need to be done in order to release and in order to be compliant with whatever regulations you may have in place. Acceptance Criteria on the other hand focus on the functionality itself and on what this functionality must do in order to be usable by users. For acceptance criteria it doesn’t matter how you write the code or test the functionality. Acceptance criteria guides us to building the right functionality and Definition of Done ensures that we have done it the right way.

Acceptance criteria are story specific requirements that must be met for the story to be completed. The acceptance criteria, specific to features, is confirmed by Product Owner who has the final say whereas Definition of Done is more of a team criteria for getting things done. A Definition of Done shouldn’t be specific to a feature or story but should span at least a project, if not all development. Acceptance criteria provide a convenient guide for testing the completeness of the story. Definition of done helps frame our thinking to identify deliverable that a team has to complete in order to build software. Such as writing code, coding comments, unit testing, integration testing, release notes, design documents etc. It is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release). The Definition of Done is orthogonal to User Acceptance criteria for a feature. In effect, every set of acceptance criteria has an unwritten first item: “Conforms to the definition of done.” Or, to put the other way around, every definition of done has as an implicit line item: “All acceptance criteria pass.” They both are aimed to improve the quality of the code produced.

Key Pointers

Definition of Done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done.

  • The definition of “done” may vary from one Agile Team to another, but it must be consistent within one team.
  • For organizations just starting to apply agile methods, the organization needs to identify the problems and work as a team to build the Definition of Done to solve them.
  • A Definition of Done that no-one knows about is next to useless. It should be easily referred to by all members.
  • If the definition of done is merely a shared understanding, rather than spelled out and displayed on a wall, it may lose much of its effectiveness; a good part of its value lies in being an explicit contract known to all members of the team.
  • Obsessing over the list of criteria can be counter-productive; the list needs to define the minimum work generally required to get a product increment to the “done” state.
  • The Definition of Done should be regularly reviewed and discussed.
  • Stories that do not meet the Definition of Done should not be shown in the sprint demo meeting. This helps reinforce the team’s commitment to getting stories done.

The evolving Definition of Done

A team’s Definition of Done is not static, i.e. it won’t remain the same throughout the lifetime of the project. As the team becomes more effective and productive, as they learn to work better together, they will naturally enhance and refine their definition of done to produce more valuable and better quality features. Over time, tightening the definition should lead to higher-quality code. Conversely, an overly long definition might be self-defeating, as people will eventually consciously or subconsciously skip steps. It’s therefore important that the team gets regular opportunities to revisit the definition of done and the natural place to do this is in the sprint retrospective meeting.

‘Done’ Takes Practice

As with many things in Scrum, understanding when something is “done” takes practice. Organizations that have just started with Agile may find it difficult to reach an acceptable level immediately. I believe that to reach a mature level of adoption large investments are required. In fact, test automation, continuous integration, releases and environments practices and a strong development approach cost money in terms of tools, training, technology, and skill.

Preparing a single “Definition of Done” that meets every situation is impossible. Each team should collaborate and come up with the definition that suits its unique environment. The team’s practices should adapt to the particular needs of the team at a given time, and may change over time as the team’s needs shift. Together, the team works with the tools of acceptance criteria and the definition of “done” to improve their work.


The Definition of Done is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. No one should neglect the importance of getting things done, and everyone needs to have a clear definition of “done” as an organization. Although this varies significantly for each Scrum Team, members must have a shared understanding of what the work needs to be complete, ensuring transparency. This “Definition of Done” for the Scrum Team is used to ensure the work reaches the quality required for the Product Increment.

The “Definition of Done” is one of the most important concepts in Scrum, yet a lot of people don’t understand it properly. Never start work on something until you have agreed on the definition.  Be consistent. Be clear. Have a shared understanding. When understood and used properly, the Definition of Done is a powerful guide for consistent quality deliverable. So make sure to get it right!



Leave a Reply

Your email address will not be published.