Skip to main content

All PBIs should pass DoD?

Last post 10:08 am February 29, 2016 by Dipankar Datta
4 replies
12:43 pm January 30, 2016

Is it necessary that all the PBIs selected in a Sprint must pass/qualify DoD to be marked as Done? Is there any scenario where it may be possible that a PBI will not be subjected to DoD?


11:51 am February 17, 2016

Hi Pradip,

If an item doesn't meet the requirements of the Definition of Done, then how can it be considered done? If you find this is happening often, I would suggest addressing this in your retrospectives and adjusting your DoD to ensure it is achievable for your team.


10:14 am February 18, 2016

A Definition of Done should assert the qualities that are expected of the increment, because it is the increment that ought to be potentially releasable. A team may plan to achieve Done any way it sees fit, including by having intermediate quality checks such as Story Done or Feature Done. Certain non-functional quality criteria, on the other hand, might be applied to the whole increment.


06:21 pm February 25, 2016

Yes, normally something is done, only if it is Done. It's actually a simple concept. DoD will make sure that we all agree what we mean when we say something is done or must be done. So we should not make exceptions in my opinion.

This DoD must be reviewed frequently preferably in the retrospectives to ensure it is improved, usually more stringent, and agreed upon.

However, there are certain scenarios where the DoD won't completely apply, but these are not scenarios defined by the Scrum Guide. For example, in our team we have decided to introduce the concept of Technical Stories (similar to Spike in XP). These are used when we don't much of a clue what approach to take to implement a story. So we create technical stories, and only once those are completed, we will look at the actual story and estimate it to be done in a future sprint. In this case, our DoD criteria such as "code must be source controlled" doesn't really apply to this technical story. We could revise the DoD though to explicitly account for technical stories as well.

Another example is when you get creative with the DoD things might change. In our team we have multiple levels of DoD due to certain reasons. So we define different levels of done, such that a PBI can be complete at only one of the levels. In particular we have Level 1: code complete but can demo to get feedback , Level 2: quality assured. Each of these levels have their own criteria, and Level 2's pre-requisite is to be at least level 1 complete. We demo things at level 1 just to get early feedback on the feature (but we make it clear that it's not yet fully tested). However, we still don't consider Level 1 stuff DONE for a potentially releasable increment. So the Sprint's DoD is still that of Level 2 of stories. This just works for us so that we don;'t delay feedback in review sessions, since you are not supposed to demo anything that is not Done.

Hope this helps.


10:08 am February 29, 2016

DOD is must I think.
For deciding whether an item is "truly" complete. If DoD is not applied on a item, it can't be dimmed as "Done".


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.