A definition of “Done” in case of many Development Teams working on a single product
up vote
8
down vote
favorite
The open scrum test contains the following question:
When many Development Teams are working on a single product, what best
describes the definition of "Done?"
A proper answer according to the test is:
All Development Teams must have a definition of "Done" that makes
their combined work potentially releasable.
However, there is another option there, which is:
Each Development Team uses its own but must make their definition
clear to all other teams so the differences are known.
And my question is that I don't really understand what's the significant difference between these two options? I deem them as very similar. They both complete each other. And I don't really think that there is anything wrong in the second statement.
Could someone give me a glue how should be more confident about why the proposed correct answer is only one correct in this particular case?
agile scrum
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
8
down vote
favorite
The open scrum test contains the following question:
When many Development Teams are working on a single product, what best
describes the definition of "Done?"
A proper answer according to the test is:
All Development Teams must have a definition of "Done" that makes
their combined work potentially releasable.
However, there is another option there, which is:
Each Development Team uses its own but must make their definition
clear to all other teams so the differences are known.
And my question is that I don't really understand what's the significant difference between these two options? I deem them as very similar. They both complete each other. And I don't really think that there is anything wrong in the second statement.
Could someone give me a glue how should be more confident about why the proposed correct answer is only one correct in this particular case?
agile scrum
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
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
yesterday
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
The open scrum test contains the following question:
When many Development Teams are working on a single product, what best
describes the definition of "Done?"
A proper answer according to the test is:
All Development Teams must have a definition of "Done" that makes
their combined work potentially releasable.
However, there is another option there, which is:
Each Development Team uses its own but must make their definition
clear to all other teams so the differences are known.
And my question is that I don't really understand what's the significant difference between these two options? I deem them as very similar. They both complete each other. And I don't really think that there is anything wrong in the second statement.
Could someone give me a glue how should be more confident about why the proposed correct answer is only one correct in this particular case?
agile scrum
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
The open scrum test contains the following question:
When many Development Teams are working on a single product, what best
describes the definition of "Done?"
A proper answer according to the test is:
All Development Teams must have a definition of "Done" that makes
their combined work potentially releasable.
However, there is another option there, which is:
Each Development Team uses its own but must make their definition
clear to all other teams so the differences are known.
And my question is that I don't really understand what's the significant difference between these two options? I deem them as very similar. They both complete each other. And I don't really think that there is anything wrong in the second statement.
Could someone give me a glue how should be more confident about why the proposed correct answer is only one correct in this particular case?
agile scrum
agile scrum
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
Andremoniy
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
Andremoniy
1466
asked yesterday
Andremoniy
1466
1466
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Andremoniy is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
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
yesterday
add a comment |
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
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
yesterday
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
yesterday
Think of a team that directly releases a product as well as the same work being used by other teams.
– Ian
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
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
yesterday
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
yesterday
add a comment |
2 Answers
2
active
oldest
votes
up vote
13
down vote
accepted
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 yesterday
Greg Burghardt
11.6k42856
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.
– Andremoniy
yesterday
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
yesterday
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
yesterday
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
yesterday
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
|
show 3 more comments
up vote
6
down vote
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 yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
accepted
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 yesterday
Greg Burghardt
11.6k42856
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.
– Andremoniy
yesterday
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
yesterday
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
yesterday
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
yesterday
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
|
show 3 more comments
up vote
13
down vote
accepted
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 yesterday
Greg Burghardt
11.6k42856
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.
– Andremoniy
yesterday
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
yesterday
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
yesterday
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
yesterday
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
|
show 3 more comments
up vote
13
down vote
accepted
up vote
13
down vote
accepted
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 yesterday
Greg Burghardt
11.6k42856
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 yesterday
Greg Burghardt
11.6k42856
edited yesterday
answered yesterday
Greg Burghardt
11.6k42856
answered yesterday
Greg Burghardt
11.6k42856
answered yesterday
Greg Burghardt
11.6k42856
11.6k42856
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.
– Andremoniy
yesterday
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
yesterday
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
yesterday
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
yesterday
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
|
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.
– Andremoniy
yesterday
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
yesterday
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
yesterday
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
yesterday
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
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.
– Andremoniy
yesterday
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.
– Andremoniy
yesterday
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
yesterday
@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
yesterday
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
yesterday
@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
yesterday
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
yesterday
@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
yesterday
1
1
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
@Andremoniy: Thanks for your comments. I have updated my answer to address some of the issues you brought up.
– Greg Burghardt
yesterday
|
show 3 more comments
up vote
6
down vote
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 yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
add a comment |
up vote
6
down vote
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 yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
add a comment |
up vote
6
down vote
up vote
6
down vote
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 yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
Pawel Gorczynski
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
Pawel Gorczynski
1691
answered yesterday
Pawel Gorczynski
1691
1691
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Pawel Gorczynski is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
add a comment |
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
Do you consider the proper answer as one's stating that all teams should share the same definition?
– Andremoniy
yesterday
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
yesterday
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
yesterday
add a comment |
Andremoniy is a new contributor. Be nice, and check out our Code of Conduct.
Andremoniy is a new contributor. Be nice, and check out our Code of Conduct.
Andremoniy is a new contributor. Be nice, and check out our Code of Conduct.
Andremoniy is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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-many-development-teams-working-on-a-single-pro%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
yesterday
Or for example the English versions of the software can ship before being translated into French,.
– Ian
yesterday
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
yesterday