Skip to main content

The DoD and Scrum artifacts

Last post 02:20 pm December 30, 2019 by Rajesh Swarnkar
8 replies
07:28 am May 1, 2013

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

03:03 am May 2, 2013

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

03:49 am May 3, 2013

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.

03:05 am May 4, 2013

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.

08:44 am May 7, 2013

What is the process to form a DoD..??

10:44 am May 7, 2013

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

01:31 pm May 8, 2013

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.

04:25 am May 9, 2013

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.

07:42 am December 30, 2019

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.