I believe that the "Definition of Done" is created by the Team and the "Acceptance Criteria" is created by the Customer. Am I correct?
Can a customer define the Definition of Done to the agile team?
Add a comment
|
4 Answers
Yes, The Definition of Done is created by the Scrum team.
The Acceptance Criteria is created by the Product Owner.
They are orthogonal concepts, but both need to be satisfied to finish a story.
-
In some scenarios PO = Customer. "The Acceptance Criteria is created by the Product Owner" is this resembles that scenario? In user story writing workshops customer write acceptance criteria in the story card. Correct me if I am wrong. I know examples for DoD criteria. Such as writing and passing unit tests, peer reviews, etc. Can you please provide me some examples of Acceptance criteria.– AkalankaCommented Jun 27, 2014 at 16:08
-
Can you improve that answer a bit? Maybe adding why are these orthogonal concepts?– JensGCommented Jul 15, 2014 at 8:54
-
I don't agree with either of these statements. Yes, a great team will come up with their own DoD, but sometimes a not so great team need pushing a little to ensure quality. Also, a Product Owner will often rely on the skills and knowledge of others to come up with the acceptance criteria. Commented Jul 15, 2014 at 15:16
-
1smp7d-s answer is mostly correct however, according to scrum.org the DoD is created by the development organization (or Development Team if none is available from the development organization)– LaCr0Commented Sep 23, 2018 at 20:57
-
@Akalanka IMHO, the Definition of Done (DoD) can be/may be created by the Scrum team (I assume you mean the Development Team of the Scrum team and not the Product Owner of the same Scrum team), but the Development Team of the Scrum team does not own or exclusively control the DoD. See my answer. Commented Dec 31, 2019 at 15:37
I don't think it is quite as cut and dry as in smp7d's answer.
The Definition of Done is created by the team, but may require the Scrum Master to enforce quality constraints if the team don't have clear development standards. For example, a team may not want code reviews or unit tests, but a Scrum Master may need to enforce them to ensure quality is maintained. In the ideal situation the team see the benefits and want such quality constraints, but the real world isn't always ideal.
The acceptance criteria should be created by everyone but confirmed with the Product Owner. For example the customer or PO may want the ability to log in, but the team add the acceptance criteria of security, performance etc. Just like creating stories, everyone can come up with ideas but the Product Owner has the final say.
Some of these things may overlap. For example in our team rather than specifying acceptance criteria around performance in every story we have moved it into the Definition of Done. A Definition of Done shouldn't be specific to a feature or story but should span at least a project, if not all development.
-
ref acceptance criteria "Just like creating stories, everyone can come up with ideas" - but aren't the acceptance criteria based on what the PO wants to have vis-a-vis his business objectives? The team hardly knows about them (at least that's my experience) because they usually have no clue about the needs of the business and the people in the trenches, for the most part.– JensGCommented Jul 16, 2014 at 8:53
-
1Predominantly yes, but the Product Owner might not know about things like security protocols that need to be met, architectural and technical requirements etc. Where I work currently ( ~ 60 developers) the Product Owner understands the business need but needs to be guided by the architectural, security, and technical requirements that fall into the acceptance criteria. I don't think this would be an uncommon situation - a Product Owner doesn't need to know all the technical stuff. Commented Jul 16, 2014 at 10:21
-
1The SMs job is not to enforce quality constraints on programming. How would they even know what quality constraints make sense, given that a SM needs no technical background?– nvoigtCommented Sep 24, 2018 at 13:30
-
1I agree, but it is a scrum masters role to ensure that an agreement on quality constraints exist, somehow. Personally I believe a good scrum master does need a technical understanding to be able to champion quality, similar to the 'professor vs entrepreneur' model. This is especially if they are dealing with new or inexperienced teams. You can get away without technical skills in very experienced teams that are already producing of high technical quality, when the role is much more focused on coaching, but personally I have never seen a non technical scrum master add a lot of value to a team. Commented Oct 8, 2018 at 10:47
https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done clearly states that the DoD is defined by the development team.
If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".
The Scrum Guide does state:
the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product
which means in the absence of a Definition of Done (DoD), it's on the Development Team to define one. However, IMHO, you can't ignore the "if" that precedes this statement:
If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product.
I interpret this to mean that some or all aspects of the DoD may be imposed on the Development Team of the Scrum Team. For example, a defense contractor wins a bid to develop a software application for a U.S. Federal Government organization and the Government organization mandates code review for all software development projects in its portfolio.
In practice, we hope that the Product Owner (probably a Government employee) and defense contractor's Development Team will collaborate to reach a mutually-agreeable DoD. But, it may be that a well-developed DoD is imposed on the Development Team by the Government through the Product Owner.
