The DoD and Scrum artifacts

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..??

Hi Alice

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.