One of the scrum tests contains the question about the definition best describing "Done" when multiple development teams perform a work on a same product.

A proper answer states that those development teams must have such a definition of "Done" that can make their combined work potentially releasable.

What is not clear for me from the proper answer to this quiz, is:

  • can teams have different definitions of "Done"? To which extent?
  • Think of a team that directly releases a product as well as the same work being used by other teams.
    – Ian
    Commented Dec 4, 2018 at 15:03
  • Or for example the English versions of the software can ship before being translated into French,.
    – Ian
    Commented Dec 4, 2018 at 15:05
  • This kind of confusion is why I never say anything is done. Instead I always say exactly what we did. Deciding if something is done is a negotiation. Not a declaration. Regardless of what definition you follow. Commented Dec 4, 2018 at 22:05

2 Answers 2


When all teams define "Done" in a manner that takes into account work completed by other teams, then you are ensuring functionality is complete.

If each team defines "done" differently and just expects the other teams to know about that definition, you'll run into several problems:

  • When an integration problem arises, no team will want to take charge of fixing it. After all, it was "done" when they started integrating things, so it must be something with the other team's work.

  • When you have more than a handful of teams, it becomes difficult to remember everyone's "definition of done" — especially when there are differences between teams.

  • The definition of done is not guaranteed to include that the integration work is functioning properly.

The accepted answer clearly states that things aren't done until the work from all teams is integrated and functioning properly. It must be releasable, and thus capable of being accepted by end users in its entirety.

Edit in response to comments: This doesn't mean every team has the same definition of done. It means part of every team's definition of done is the larger system and other integrating components are not broken.

  • I beg your pardon, but it seems to me that the correct answer says nothing about having the single definition of "Done". Moreover, I am not sure that integration peculiarities must be included in it. Say if two teams both working on a completely different implementations of the same API dedicated for different customers? However formally they are still working on the same product.
    – user174829
    Commented Dec 4, 2018 at 14:03
  • 2
    @Andremoniy, the correct answer indeed does not say anything about a single DoD, but it does mean that the DoD's of all teams should have a common element that the overall product remains functional. Your example of different teams working on different implementations of an API does not convince me that that could be called a single product. Commented Dec 4, 2018 at 14:14
  • 2
    @Andremoniy, as soon as one team depends on the work of another team, integration issues can (will) occur, even if the parts are deployed to different locations. It is also an integration issue, for example, when one micro-service uses another micro-service in an unexpected, possibly incorrect, way. Commented Dec 4, 2018 at 14:29
  • 2
    @Andremoniy: You are right that those two teams shouldn't use the same DoD, but they can share the rule that any changes must not negatively affect the other team (which would mostly trigger if the work involves changes to the interface with the back-end server). Commented Dec 4, 2018 at 14:47
  • 1
    @Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up. Commented Dec 4, 2018 at 16:32

I could imagine a situation, where one team defines "Done" as "Development Done" (i.e. code merged to repo) while other defines it as "Testing Done" (i.e. code released to Q/A and tested).

This would inherently lead to serious problems because the overall product state would be largely undefined and hence it would be hard to tell whether we can actually release it or not.

  • Do you consider the proper answer as one's stating that all teams should share the same definition?
    – user174829
    Commented Dec 4, 2018 at 14:03
  • Yeah, I'd agree that there should be a common definition for a simple reason - A complex project can be considered a tree structure where subprojects (e.g. microservices) build up the overall product (e.g. MyCool ERP). So in a given moment of time, you want to know if a new version of the product can be released. But if you have different DoD for particular subcomponents, then this information becomes extremely hard to deduce. Commented Dec 4, 2018 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.