Skip to main content

Definition of Done

Last post 03:18 pm July 14, 2022 by Daniel Wilhite
4 replies
08:27 am July 14, 2022

Hi all!

At the moment we are creating DoD for our team - automatic tests and documentation is a MUST for now.

The problem (or challange) is we have a lot of different things to take care of. We have support, main product X, product X for version 1.0, 2.0, 3.0, application for translations, projects, documentation and different type of issues(epics, stories, documentation, spikes, bugs, tasks and maybe different types in the future). It is a very hard task to do to create one DoD for all issues.

And what have we done? We have created DoD for tasks that have PR(pull request) - it is condition, so tasks that does not have PR(f.e. spikes) does not have DoD.

We want to continue with learning about DoD but my question to you guys is... What do you think about that? Is it good aproach?

 

Best Regards,

Mario.


08:56 am July 14, 2022

If it works for the team, and gives them confidence in the quality of the Done increment, then it's hard to say it could be a bad idea. 



I would suggest two things though based on patterns i've seen; 



If there is so much to do that creating a DoD is hard, this probably deserved it's own retro. How do we simplify, automate, or throw away processes that aren't actually helping us?  This thing with multiple versions, as well as documentation, sound like prime candidates to inspect and adapt. 



secondly, don't try to solve with a DoD what can just be solved with technical practice. 



Ie, if you can make something a requirement against the PR, then it probably doesn't need to be called out in the DoD. Simply meeting the requirements for the PR will ensure quality. 



Remember that the value of the DoD is not as an artifact, it's in the quality that results. That's the thing we're optimizing for. Ensure your DoD captures the things needed to create the desired quality that might otherwise be missed. You don't need to state the obvious, and you don't need to write down things that will happen anyway. 


01:45 pm July 14, 2022

At the moment we are creating DoD for our team 

There's your problem, right there. A Definition of Done is for the product. It's a guarantee of usable quality for each product Increment. It isn't per team.

If you have multiple products and product versions, the value of each of which needs optimizing and accounting for, then each would need a DoD to assure an increment's quality. Transparency is needed over these separate value streams, their quality, their prioritization, and the focus your team is losing by taking them all on.

 


02:10 pm July 14, 2022

I wrote an article that may help:

https://www.agileconnection.com/article/using-definition-done-promote-continuous-improvement


03:18 pm July 14, 2022

One thing I advocate is that you don't look at the different things you do as different types.  Everything is a Product Backlog Item.  Treat them all equally. 

Second thing I advocate goes along with @Ian's response.  The Definition of Done is not about the different items you do or the team.  It is about the Product.  It is a written agreement by the Scrum Team that will indicate the quality and state of the Product iteration when the team states it is "Done".  It should be easily understood by parties outside of the Scrum Team because the intent is for them to better understand what you mean by "Done".  

There can be an organizational level Definition of Done and then each team can create their own to add further guidance for the product that they support not the items that they complete.


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.