A definition of “Done” in case of several Development Teams working on a same product
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?
agile scrum
add a comment |
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?
agile scrum
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 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.
– candied_orange
Dec 4 '18 at 22:05
add a comment |
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?
agile scrum
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?
agile scrum
agile scrum
edited Dec 10 '18 at 12:58
asked Dec 4 '18 at 13:31
user174829
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 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.
– candied_orange
Dec 4 '18 at 22:05
add a comment |
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 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.
– candied_orange
Dec 4 '18 at 22:05
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 at 15:05
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 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.
– candied_orange
Dec 4 '18 at 22: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.
– candied_orange
Dec 4 '18 at 22:05
add a comment |
2 Answers
2
active
oldest
votes
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.
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
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
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
|
show 3 more comments
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.
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f382441%2fa-definition-of-done-in-case-of-several-development-teams-working-on-a-same-pr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
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
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
|
show 3 more comments
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.
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
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
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
|
show 3 more comments
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.
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
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.
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
edited Dec 4 '18 at 16:31
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
answered Dec 4 '18 at 13:42
Greg BurghardtGreg Burghardt
12.8k42957
12.8k42957
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
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
|
show 3 more comments
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
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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.
– Bart van Ingen Schenau
Dec 4 '18 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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
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
Dec 4 '18 at 14:03
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
Dec 4 '18 at 14:03
2
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.
– Bart van Ingen Schenau
Dec 4 '18 at 14:14
@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.
– Bart van Ingen Schenau
Dec 4 '18 at 14:14
2
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.
– Bart van Ingen Schenau
Dec 4 '18 at 14:29
@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.
– Bart van Ingen Schenau
Dec 4 '18 at 14:29
2
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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
@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).
– Bart van Ingen Schenau
Dec 4 '18 at 14:47
1
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
Dec 4 '18 at 16:32
|
show 3 more comments
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.
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
add a comment |
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.
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
add a comment |
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.
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
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.
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
answered Dec 4 '18 at 13:47
Pawel GorczynskiPawel Gorczynski
2192
2192
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
add a comment |
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 at 14:03
Do you consider the proper answer as one's stating that all teams should share the same definition?
– user174829
Dec 4 '18 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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
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.
– Pawel Gorczynski
Dec 4 '18 at 14:10
add a comment |
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f382441%2fa-definition-of-done-in-case-of-several-development-teams-working-on-a-same-pr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
Dec 4 '18 at 15:03
Or for example the English versions of the software can ship before being translated into French,.
– Ian
Dec 4 '18 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.
– candied_orange
Dec 4 '18 at 22:05