Skip to main content

What to put in the Defenition of Done

Last post 02:42 am February 21, 2014 by Benjamin Korth
2 replies
09:12 am February 20, 2014

Hello,

I try to set up a Scrum process and asking me what to put in the Definition of Done (DoD). I see the DoD as "terms of use" for the Development Team.
Like "implement this requirements but make sure you have done system testing and integration testing". As the guide says, it should be used to assess the product increment.
My question is can I put some weak formulatings in it or is it recommended only to be hard, measureable facts?

1)
I want to structure the DoD that there is space to include best practises on software development and rules the Development Team made themselve. For Example: "Make your function name explaining what the code does." or "Try to avoid commenting you code and make it self explaining".
This could be evaluated by a code review. On the other hand I could shift this into a coding guidline and refere from the DoD like: Code review must be done against the coding guidline.

2)
The second point is about technical depts like in the discussion https://www.scrum.org/Forums/aft/663#3526. In this case I mean smelly code that needs to be refactured to gain maintainabillity.
I would like to put in the DoD: Code must stay maintainable. Every action that is needed must be made by the Development Team to ensure maintainabillity.
Or should I define a test or metric to ensure maintainabillity?


Background:
This is all about code and product quality and therefore I want to have this in the DoD.
Another point to have it there is that the Product Owner (PO) and the Development Team (DT) aggreed on this quality level.
In my opinion the Development Team knows very good what make sense to produce high quality products, but under pressure they start to trade qualtiy against velocity.
The PO tries to get more for less and might not see how he accidentily causes the DT to focus on velocity and they start to forget their good intentions to produce high quality code.
And I understand this as it seems that nobody but the DT seems to concern about the quality. The truth is that the quality standards are just not transparent. But If I put this in the DoD then it is like an aggreement between the PO and the DT that they get the time to produce qualtiy and that they have to produce this kind of qualtiy.

I look forward to get your responses


11:54 am February 20, 2014

> My question is can I put some weak formulatings in it or is it recommended only to be hard, measureable facts?

The hard, measurable fact is that work is either Done or not Done. The Definition of Done can consist of weak formulations as long as it is agreed, by the end of the Sprint, that the work is fit for potential release by the Product Owner. The stronger those formulations are the easier this will be.

> I want to structure the DoD that there is space to include best practises...

That's not a good idea, because the purpose of a DoD is to determine whether or not an increment is potentially releasable. If certain practices must be observed in order to meet that criterion, then they are essential practices and not just best ones.

Unit testing may be essential, as might a certain degree of code coverage. They could reasonably make it into a DoD and no release would be possible unless those terms are satisfied. On the other hand, following certain commenting conventions might be a best practice, but should a release be held hostage to it?

> I would like to put in the DoD: Code must stay maintainable

That depends upon whether or not maintainability is considered essential for release. This is a joint Scrum Team decision based upon the Product Owner's strategic vision for the product, and the Scrum Master and Development Team's understanding of how future work could be affected.

> should I define a test or metric to ensure maintainabillity?

If you can define a test or metric to ensure maintainability you are set to make a fortune.


02:42 am February 21, 2014

Hello Ian,

I will not put an best practise document into the DoD as you suggested. With the whole Scrum Team together I will formulate a kind of manual tests set and reviews that must be done before an increment could be released in order to have a certain level of quality.
I will start with the most easy formulating of these test cases or acceptance criteria and adapt if neccessary.

Thank you for your advice!


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.