Definition of Done

Last Update: 4/3/2017

Team Services | TFS 2017 | TFS 2015

As your team updates the status of work as it progresses from one stage to the next, it helps that they agree on what “done” means. By specifying the Definition of Done criteria for each Kanban column, you help share the essential tasks to complete before moving an item into a downstream stage.

Also, you'll have implemented one of the core Kanban tenets: make processes and policies explicit.

When set, team members can quickly double-check the done criteria.

Definition of Done

If you're just getting started, review Kanban basics to get an overview of how to access your board and implement Kanban.

Specify the Definition of Done for a column

  1. From your Kanban board, click settings icon and as needed, click Columns.

    Kanban board, open common configuration settings

    If you're not a team administrator, get added as one. Only team or project administrators can customize the Kanban board.

  2. Open the Definition of Done for the column that applies to the criteria you'll enter. You can specify the Definition of Done for each intermediate column on your team's Kanban board.

    Team Services and TFS 2015.1 and later versions
    Click a column tab and enter the Definition of Done for that column. Enter text that defines your team's Definition of Done.

    Kanban board, Coding column tab, Definition of done]

    TFS 2015

    Edit Definition

    Enter text that defines your team's Definition of Done.

    Definition Text

  3. Team members can quickly check that they have met the criteria by clicking the Information tooltip Info Icon icon.

Your team, working software and the Definition of Done

One of the 12 principles of Agile software development is to “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

All agile teams must establish what they mean when they say "working software," which is frequently known as the definition of done. At a high level, a piece of functionality is complete only when its features pass all tests and can be operated by an end user. At a minimum, teams must go beyond the unit test level and test at the system level. The best teams also include integration testing, performance testing, and customer acceptance testing in their definition of what it means to be done with a piece of functionality.Agile Principles and Values, by Jeff Sutherland

One of the major causes of teams failing to implement Agile is they lack good definitions of done.

Each stage indicates a handoff to someone else who will do work. What information does the next person in the flow sequence need to quickly succeed. Incomplete work or uncommunicated information can lead to delays and wasted effort.

As a starting point, consider some of the following criteria as you work with your team to decide what done means throughout the development process.

Stage Done criteria
Before work starts on a feature, user story, or requirement
  1. User story is properly scoped and estimated.
  2. Acceptance criteria is well defined.
  3. Customer needs are understood by the team.
  4. Dependencies have been identified and are tracked.
Bug filing
  1. Bug title identifies the issue clearly.
  2. Repro steps are clear and minimal.
  3. Bug specifies a single issue.
  4. Related issues are linked to as related.
  5. Terms used are clearly understood within the team.
Code complete, ready for testing
  1. Code complete, commented, and run against current version.
  2. Code peer reviewed and meets team standards.
  3. Builds without error.
  4. Passes unit and system tests.
  5. Remaining hours for tasks set to zero and task closed.
Test complete, ready for release
  1. Unit tests implemented for all new features or functions.
  2. Unit tests are all passing.
  3. Acceptance/story tests are written and passing.
  4. Regression tests are green with known failures.
  5. Sufficient exploratory testing has been done.
  6. Feature/function works correctly as expected.
  7. Unsolved defects have been logged as bugs.
  8. Code coverage is stable or improving.

As your team makes progress, revisit your Definition of Done criteria.

A development team's Definition of Done is meant to expand over time. A newly formed team will invariably have a less stringent and smaller Definition of Done than a more mature team with a shared history of improving. Expanding a team's Definition of Done lies at the very core of Kaizen, a Japanese term meaning a mindful and constant focus on improvement. While a team may initially require only that code build before being checked in, over time they should evolve more exacting standards like the need for unit tests to accompany new code.─ David Starr, Effective Sprint Retrospectives

Acceptance Criteria versus Definition of Done

Acceptance criteria corresponds to what a customer should expect when a user story, feature, or requirement has been implemented. Conversations between the team and customers to determine the acceptance criteria helps ensure a common understanding within the team to meet customers' expectations. The acceptance criteria can be used as the basis for acceptance tests so that the team can more effectively evaluate whether an item has been satisfactorily completed.

Acceptance criteria defines when a feature is shippable. Capture the criteria for each backlog item in the Acceptance Criteria field (for Scrum product backlog items) or the Description field (for Agile user stories and CMMI requirements).

Acceptance criteria field on work item form]

The Definition of Done, on the other hand, is about delivering an incremental piece of a feature as it moves from not started to complete. Agile teams meet with greater success when each handoff made is in a ready state for the recipient to begin their work.

Agility requires delivering done, ready-to-use increments of working software each Sprint. Yet most Scrum and agile teams generate partially done, incomplete Increments. When a Scrum Team is asked why Product Backlog requirements were not completely done in a Sprint, team members often reply, “We didn't have time.” ─ Ken Schwaber and David Starr, Done and Undone

See these choices for further options to customize the Kanban board: