The DoD and Scrum artifacts
The Scrum Guide lists the Product Backlog and the Sprint Backlog as its two Scrum artifacts. The Definition of Done is not an artifact. I was wondering if anyone has thought about that?
Other parts of the Scrum Guide say: "Scrum users must frequently inspect scrum artifacts ..". The Definition of Done is also a subject of continuous inspection. Apparently it shares properties with the Scrum artifacts especially its need for transparency.
I assume that the Scrum Guide is a result of inspection itself. Would you be willing to consider the Definition of Done as an artifact? Why am I asking you?
In my daily practice I noticed that occasionally Items of the Product Backlog are in fact requirements. In the Sprint Planning Items wander from the Product Backlog to the Sprint Backlog. According to https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done the Sprint Planning Meeting is also the occasion to inspect the Definition of Done:
"During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, which enables the Development Team to know how much work to select for a given Sprint."
That statement confirms the close relationship of the Definition of Done with the Scrum artifacts. I assume that the authors of the Scrum Guide have been considering this too. What made them decide against the thought that the DoD is not a Scrum artifact?
I don't think there is any artifact called DoD, it is an umbrella process which must be followed for ensuring that all sprint backlog items are ship-able.
Also I have seen teams using a DoD checklist in excel format and sharing it daily within team and PO for making sure that everyone is on same page w.r.t. sprint status for each PBI
In the Scrum Guide, the Definition of Done is placed at a peer level to the Scrum Team, Scrum Events, and Scrum Artifacts. It isn't classed as an artifact itself, presumably because it isn't part of the product value stream in the same way that backlogs and increments are. It's a more fundamental part of the process.
Thanks Sanjay and Ian for joining me in this discussion.
@Sanjay, an excel sheet actually is an artifact, right? I mean to say that we might have on a converting mind track.
@Ian, I understand that you seek a distinction in the nature of the DoD compared with both artifacts. I agree that the DoD has an on-going nature where each item of the artifacts have an incidental "definition of done" themselves.
I came to this issue because I noticed that occasionally Items of the artifacts move to the DoD. In rare occasions even back, for instance with BDD. This is mostly done by the Scrum Development Team, who is responsible for the DoD. (Source: Developer Open Assessment).
I have a desire to check my perception of the Scrum definition. If I follow Ian correctly then I could argue that each Backlog Item needs a "micro DoD" section that extends the DoD.
I wonder how Ken and Jeff think about this. Does anyone know how to ask them for their guidance.
What is the process to form a DoD..??
I don't think there's a defined process, but I suggest:
1) Review Acceptance Criteria:
a) Gather the Acceptance Criteria for work completed so far
b)) Look for common criteria that can be abstracted out and applied across work in general
c) Use these common criteria as the basis for a Definition of Done
2) Assess Technical Debt
a) Identify any rework that needs to be done
b) Identify the reasons why it wasn't done properly the first time
c) Identify what measures can be put in place to stop similar rework from occurring
d) Add these measures to the Definition of Done (DoD)
3) Continually update the DoD
a) In each Sprint Review, identify which (if any) work was rejected or which caused rework to be done, then
b) In each Sprint Retrospective, challenge the DoD for relevance and completeness
Good question Alice. That's a very useful checklist Ian. Thanks.
If we add "measures" to a DoD, would that violate its nature? A measure supports a process. The Scrum Guide defines the DoD as
a shared understanding of what it means for work to be complete
. An elegant and open way of defining the DoD for it does reveal its significance but does not prescribe its manifestation.
I assume that you suggest to use the results of the measures, rather than the measures themselves. Could you please clarify Ian.
The DoD can be written in any form, or not written at all. As you point out it is a shared understanding. If it is written down, I'd suggest using the same format as acceptance criteria (Given...where...then). So in a retrospective a team would challenge those criteria and rewrite them as necessary. It is rather prescriptive but arguably conforms to the principle of least surprise, and the terms can be refactored from the DoD to a/c or vice-versa as scope clarifies.
All but the most mature teams will need a DoD that is documented in some form. A summary of the criteria can be written on an index card and placed above the "done" column on a Scrum board as a reminder.
The whole idea of DoD not being included in artifact can be seen on this blog post here.
Should DoD be written down, passed around, made into an official artifact of the project? I don’t think so. To do so will almost guarantee that it becomes a political football, a thing to measure, and a bludgeon. You can write it down, post it on walls, create shrines to it, if you wish.
But what it is supposed to be is a common understanding among all the team members, their Product Owner, and all their stakeholders, of the current meaning of quality in the Product Increment. A common understanding cannot be created by publishing a document: it comes from working together to create understanding, not to hammer out a piece of paper.
Not having too rigid condition helps in planning less and It fosters scope of change request and thus serving openness and respect in and out scrum team.