Changing the Definition of Done

The definition of done is a checklist of the types of work that the team is expected to successfully complete by the end of the sprint, before it can declare its work to be potentially shippable. A team’s definition of done should be determined before it does its first sprint. A bare-minimum definition of done should yield a complete slice of product functionality, one that has been designed, built, integrated, tested, and documented and will deliver validated customer value.

Once a Scrum team has established its definition of done can it be changed? Well, yes and no. Let me explain.

Don’t Weaken the Definition of Done During a Sprint

During a recent coaching session I was asked whether it was acceptable to change the definition of done during the sprint. The specific circumstances for this team were that its definition of done required testing on a QA Test Server before it could claim a product backlog item is done. For reasons outside of the team’s control, the QA Test Server had not yet been properly configured and there were only two days left in the sprint. If the server failed to become available soon, the team would by definition not be able to complete any of its user stories that sprint.

So, what to do? Should the team remove the “Successfully tested against the QA Test Server” as a criterion in its definition of done this sprint? As a general rule, no, the team should not remove this criterion. My logic is that there can always be some kind of impediment that blocks a team’s ability to get the job done and I want to make both the impediment and the effects of the impediment visible to everyone involved (especially to those who have the ability to remove such impediments). I feel it is a slippery slope to adopt a policy of weakening the definition of done in the middle of a sprint. So my rule is don’t weaken the definition of done during a sprint.

But If We Don’t Weaken, We Won’t Have Anything to Show at Sprint Review

Ok, let’s say we don’t alter the definition of done in the above scenario. That led to a very practical follow-on question from the team. Basically, “If we don’t change the definition of done, then no items will be done this sprint, so what would we show at the sprint review?” As a rule, you are only allowed to show done items at the sprint review, so this is a good question.

Should the team cancel the sprint review? If the team holds the sprint review the stakeholders wouldn’t see any newly completed (done) features, so the meeting itself would focus on the team explaining its goal for the sprint and then stating that nothing was completed towards that goal. You might argue that the ensuing discussion about why the team didn’t get anything done could be illuminating. If so, then the team should go ahead and do the sprint review.

What if the team feels it would be a waste of time to not show anything at the review? If there is nothing to show, there might be nothing tangible to promote an inspect-and-adapt discussion (which is the purpose of the review – see blog post It’s a Sprint Review, Not a Sprint Demo!).

If the team feels doing the sprint review would be a waste of time, there are two options. First, don’t do the sprint review thus avoiding the wasting of valuable stakeholder time.

Second, do the review and show the work that is in the state of “all but QA Server Tested.” Make sure to explain to the stakeholders that what they are seeing might change once the testing on the QA Server takes place. Even though items might change based on the results of the testing, the team, and more importantly the stakeholders, might still feel it is beneficial to show undone work (thus violating the rule that teams only show done items at a sprint review – hey it was a rule, not a law!).

You Can Strengthen the Definition of Done During a Sprint

Can the definition of done be strengthened during a sprint? Personally, I am okay with doing so, when it makes sense. Let me use an example.

I work with a number of companies that build products that are a combination of hardware, firmware, and software.  Early on during development let’s say a software team is building features that eventually have to be deployed on the hardware that is being developed in parallel by another team. Until there is some version of the hardware available to the software team, think about how “done” the software features can be at the end of a sprint.

In many of these companies, they create a software emulator of the hardware and the software team would initially test its new features against the emulated hardware. So, until a usable piece of hardware is available to the software team, its definition of done would effectively be “emulator done.”

However, once the hardware becomes available, “emulator done” would no longer be a sufficiently robust definition of done. So, the team would remove “Successfully tested against hardware emulator” from its definition of done and replace it with “Successfully test against hardware.” Doing so effectively strengthens the definition of done.

Now, what if the hardware becomes available early in the sprint and the team believes that it will not jeopardize the sprint goal by strengthening its definition of done to test on the actual hardware this sprint? I say the team could and should change its definition of done at that point during the sprint.

On the other hand, what if the hardware arrives at a point during the sprint where the team cannot reasonably test the features being developed this sprint against the newly arrived hardware without putting the sprint goal in jeopardy? Then it should not change its definition of done this sprint. Which leads to my last rule.

Preferably Change the Definition of Done at Sprint Boundaries

The preferred time to make a change to the definition of done is at sprint boundaries. Changes at the boundary between two sprints avoid most of the issues that I detailed above.

Just so we are clear, the definition of done can evolve over time as shown in the previous hardware example. In fact anytime a significant impediment is removed from or by the team becomes an opportunity to strengthen the definition of done.

For example, let’s assume that up until recently we only had one small team in the company that does performance testing. All other teams in the company use the same performance testing team to do performance testing on their behalf. However, we have hired and trained other people on how to do performance testing and now each Scrum team has its own performance tester.

In this scenario, “Performance testing” was probably not originally a criterion in the definition of done of any team that previously relied on the performance testing team. But, since the impediment surrounding performance-testing resources has been addressed, perhaps now it can be included in the definition of done.


The definition of done is an important list of criteria that a Scrum team uses to determine if the work completed in a sprint meets the proper level of completeness (like potentially shippable). As a rule, don’t weaken your definition of done during a sprint to circumvent an impediment. However, you can strengthen your definition of done during a sprint if doing so doesn’t jeopardize your sprint goal. As a preferred strategy, strengthen your definition of done at sprint boundaries.