Definition of Done

Definition of Done

The Definition of Done is important for all teams to agree on because it gives everyone a shared understanding of when something is complete.

To understand how the Definition of Done works, imagine something like an apple – it always starts as a seed first. It needs proper environment, nourishment and care, and goes through different growing phases until ultimately becoming fruitful (i.e. valuable). Each phase has to be complete before the next phase begins.

Similarly, a product or feature starts with an idea, originating from problems or opportunities heard or from any of the product manager’s listening channels (customers, associates, internal team, stakeholders, data, etc.). Then the idea goes through different phases.

First, you start with a discovery process to gain a better understanding of the problem. Next, you come up with a few solution ideas that may address the problem. If an engineering solution is required, then you move onto the next phase, and collaborate with your balanced team to define, build and deliver your solution.

Your work is still not done! Delivering a solution only covers part of the done. At this point, you still need to measure and determine if you achieved your desired outcome.

Remember your agreement and Definition of Done. Work is only done when the expected outcome has been achieved and the fruits of your labor can be enjoyed.

This process is a continuous loop until you’ve achieved the outcome.

Focus on these Definition of Done Phases:

  • Definition of Done: Problem Definition/Discovery
  • Definition of Done: Story Readiness
  • Definition of Done: Story Completion
  • Definition of Done: Production Release
  • Definition of Done: Outcome Measurement

Each phase has decision makers. This is because the Definition of Done document is a team document we all contribute to and agree on. Furthermore, it is a living document and should be updated as team dynamics change.

Definition of Done: Problem Discovery

First and foremost, the problem must be understood and defined well through a discovery process — a feature request or idea can never be peppered with too much questioning.

Here’s a checklist to help you get to the core problem:

The Decision Makers:

  • The Balanced Team (level of involvement for each team member may vary depending on the nature of the story and the product)
  • Stakeholders to identify dependencies and agree on the problem statement

Problem Discovery Checklist:

  • Define the user
  • Create a user persona
  • Define the problem
  • Create a journey map
  • Write a problem statement “We have observed that…which is resulting in…How might we…Such that…” (See the attached artifact)
  • Collect data on the problem size
  • Identify how the problem is being solved today
  • Identify a measure of success and tie it to the “such as” part of the problem statement
  • Define solution options
  • Write a Leap of Faith statement
  • Identify opportunities from the problem statement
  • Identify possible solutions from the opportunities
  • Identify assumptions that drove you to the solution ideas as well as assumptions contained within your solutions
  • Conduct experiments and discovery tasks to minimize risk from your identified assumptions
  • UX: Create UX proof of concepts
  • Product and UX: Collect data and answers to business unknowns
  • Engineering: Complete spike work to answer technical unknowns

Through the discovery phase you may find that a technology solution may not be the correct approach. In that case, you can skip the engineering solution phases. However, there may still be work to usher in different business processes. If your discovery work identified a solution that requires engineering work, then move onto the next step.

Note: The discovery phase doesn’t need to be done for every story written. Stories within epics that have gone through the discovery phase can inherit the findings.

Definition of Done: Story Readiness

Once the problem is well understood and it comes time for your team to start on it, the story will need to be ready before developers write any code.

A story is “ready” when the story is groomed, and engineering is ready to start.

The Decision Makers:
The Balanced Team (level of involvement for each team member may vary depending on the nature of the story and the product)
The Stakeholders to identify dependencies and agree on the solution
The Product Manager of any technical dependencies or stakeholders for business dependencies

Story Readiness Checklist:

  • Describe in simple terms the problem, not solution (“What” and “Why” – not “How”)
  • Write with INVEST criteria
  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable
  • Clearly define the acceptance criteria (see included example Given, When, Then structure)
  • Estimate in terms of complexity for what works for your team (in Fibonacci or a t-shirt size for example) and should be small enough to be done within an iteration.
  • Identify and solve internal/external dependencies
  • Identify and align with stakeholders (if more than one stakeholder, use a stakeholder map). Consider legal, marketing, support, compliance, learning & training, etc.
  • Identify Measure of Success and tracking mechanisms
  • Consider how these changes may affect your upstream or downstream partners

Definition of Done: Story Completion

The story is picked up by engineering and development is in progress — great! At this point, the engineers should have all the information on why and what they are expected to code and aware of the dependencies that may impact the story completion. Unknowns may still be discovered in the process. Things happen at this stage that could impact the story as it evolves from on-paper to in-code. Given this, how will the team know when development is complete? Here’s where a Definition of Done for story completion comes into play.

The Decision Makers:

  • The Balanced Team
  • Engineer: the coding is complete
  • Product: acceptance criteria
  • UX: design aspects meet expectations

Story Completion Checklist:

  • UX reviews
  • Engineer peer review
  • Testing: unit tests pass
  • Testing: automated tests pass and/or end-to-end testing
  • Testing: manual tests pass
  • Meets all acceptance criteria
  • Monitoring, Metrics, Logs: Necessary logging to monitor use, performance, problem analysis in place
  • Make sure to cover measure of success
  • Documentation: Capture anything useful for how it works to get others up to speed on it quicker or share with other teams or stakeholders.

The story completion definition of done list can become highly customized by each team.

Definition of Done: Production Release

Once the story is completed, it’s ready to be deployed to production. Below are common steps teams take for production releases.

The Decision Makers:

  • The Balanced Team for coordinating deployment
  • Business Stakeholders for operational / process change management

Production Release Checklist

  • Communicate and Coordinate Change Management
  • Let stakeholders know before deployment so they can prepare (such as WIN policy for stores)
  • Release note
  • Deploy
  • Test
  • Integration Testing
  • Regression Testing
  • Manual Testing
  • Universal Truths Testing
  • Monitor
  • Post-release monitoring and tracing, including Universal Truths

Definition of Done: Outcome Measurement

The story is now in production and working, great! But not done! You still need to measure the outcome to know whether or not it was successful. Sometimes success or failure may be clear at this point, but it may take a while for the desired behavior to occur.

The Decision Makers

  • The Balanced Team
  • Stakeholders

Outcome Measurement Checklist

  • Continue to track the success metric after the feature has been rolled out:
    If the feature was rolled out early in the OKR quarter, track and report outcome metrics on the quarterly priority board (OKR) in the short term
    Some metrics may have to be tracked beyond the OKR quarter. Add such outcome metrics to a long-term KPI dashboard that tracks your product’s long-term vision. This will provide visibility into the trends of your product over time.
  • Document learnings (a learning ledger is a useful tool for this purpose)
  • Did the solution achieve the expected outcome?
  • If so – great. If not, what else can we do?
  • Continue to update stakeholders on the outcome and learnings

Congratulations! Once you have determined the expected outcome has been reached, we can then say that the problem has been D-O-N-E.

It’s an Evolving Process

Remember, your agreed definition of doneness will change as your team progresses through their work. Along the way, you will learn how to get better as you continually understand the nature of your work. Review your team’s definition of done phases as needed. Typically, this happens a few times each year, especially when your team takes on new technology or when new people are added to your team.

Helpful Templates:

Problem Statement Format:

  • We have observed that [some problem or opportunity exists],
  • which is resulting in [negative effect if a problem or missed business opportunity if not pursued].
  • How might we [a strategy for addressing a problem or opportunity space] such that we achieve [some value goal]?

Leap of Faith Statement Format:

  • We believe that [capability]…will result in [this outcome]…We will do [this test]…We will know that our hypothesis is valid if we observe/measure [this outcome].

Acceptance Criteria Format:

  • Scenario: [Concise title for test case] (Cover Happy, Sad, Exception Paths)
  • Given: [some precondition]
  • When: [user does some action]
  • Then: [user expects some result]