DoD, Does it only apply to the Increment?
I am trying to get clarity regarding the coverage of the Definition of Done (DoD). I seem to be getting different responses and I thought I'd start a new thread dedicated to this and re-ignite this conversation.
So, my understanding is that the DoD is applicable both at the Product Increment level and also at the Product Backlog Item (PBI) level.
Here's my reasoning with lines from the Scrum guide.
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.
My interpretation of the above is that it is both applicable to the PBI as well as the Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.
Just as I mentioned above, another line that justifies my interpretation.
Now, I need some clarity when this is applied to scale.
If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
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".
What I understand from the above is that if the organization has a DoD then all Scrum Teams must follow that while producing their integrated Increment.
Now, if the organization does not have a DoD, then Development Team(s) should define an appropriate DoD.
So, if there are multiple Scrum Teams working on the same Product, then my understanding is that they should all together, mutually define a single DoD that is applicable to all of them. Is there any reason or exception why individual Scrum Teams will have their own DoD and a shared DoD?
Or rather, is it a true statement that when multiple Scrum Teams are working on the same Product, then each Scrum Team is free to have their own DoD but should also ensure that a common DoD exists for the Integrated Increment?
I would tend to agree with you in that the Definition of Done applies to both Product Backlog Items as well as the Increment. I believe that this is consistent with the parts of the Scrum Guide that you quote, but what isn't clear is if there is a single Definition of Done or two Definitions of Done (one for Product Backlog Items and one for the Increment). I'd have to reason through a bunch of cases to see if I would be able to find cases that support one idea or the other.
As far as where the Definition of Done comes from, I interpret the Scrum Guide as indicating that the organization is the first source for a Definition of Done. If the organization does not provide one, then the Scrum Team must develop one. If there are multiple Scrum Teams, then there must be a baseline Definition of Done that applies to all of the teams. However, any Scrum Team (in the case of one team or many teams) may decide to enact a more stringent Definition of Done than the baseline Definition of Done.
Or rather, is it a true statement that when multiple Scrum Teams are working on the same Product, then each Scrum Team is free to have their own DoD but should also ensure that a common DoD exists for the Integrated Increment?
Yes, although it's important that the common DoD should not only exist but be understood.
"Done" can exist at multiple levels. It must ultimately apply to an increment, and to that end, everyone in a team should understand what "Done" means.
Yes, although it's important that the common DoD should not only exist but be understood.
"Done" can exist at multiple levels. It must ultimately apply to an increment, and to that end, everyone in a team should understand what "Done" means.
@Ian Mitchell, In a scaled scenario, why would the individual teams need their own DoD instead of having a common DoD? Isn’t that considered a waste?
Similarly, when you say “Done” can exist at multiple levels, could you clarify what those levels are, please?
In a scaled scenario, why would the individual teams need their own DoD instead of having a common DoD? Isn’t that considered a waste?
Suppose one team worked on a desktop application, another on mobile, another on the user guide, another on marketing material. All of this work must be integrated for a viable release to happen. There must be a DoD which assures this, and yet each team's level of Done might assert different things considering the different work they do.
Similarly, when you say “Done” can exist at multiple levels, could you clarify what those levels are, please?
For example, in a scaled or unscaled scenario, acceptance criteria might represent the level of Done that is appropriate for an individual item. There must nevertheless be an understanding of Done which assures the integration of work into a releasable increment.
@Ian Mitchell, Agreed that acceptance criteria can satisfy criteria for completion for an individual PBI, but shouldn’t the same PBI also be checked against the team’s DoD too? Or do we only consider the final Increment to be checked against the DoD?
shouldn’t the same PBI also be checked against the team’s DoD too? Or do we only consider the final Increment to be checked against the DoD
Correct, as "Undone" work is not part of the Increment and thus inherently needs to be checked against the DoD.
I view the organizational DoD as those things that everyone would have on their team DoD. But some teams may have more stringent criteria that they want to apply. For example an organizational DoD might say that all code must be peer reviewed. A team may state that all code must be reviewed by 2 or more people. Or an organizational DoD may say that the code must be in use in Production for 36 hours without major incident. A team DoD may add that all code must be used in Production by a specific set of users for 48 hours without major incident prior to being released to the entire user base.
As for Acceptance Criteria, I see those much like a third layer of DoD. Everything is subject to all DoD that exist but specific items may have additional criteria. I also coach that Acceptance Criteria defines how you will know that the problem described in the Backlog Item is satisfied which can be different than the DoD if the DoD is more focused on procedural topics.