Skip to main content

About the DOD

Last post 06:05 pm January 29, 2024 by Daniel Wilhite
6 replies
04:47 pm January 23, 2024

Hello dear community,

It says about responsibility for the DOD:

If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

So the Scrum Team may have to create the DOD, OK

I'd like to know if the DOD is formulated using appropriate documentation within the Scrum Team when it is non-existent. I'm working on a project where neither the stakeholders nor the Scrum Tean have explicitly formulated a DOD to validate the increment produced when the sprint ends.

I'd also like to know whether the implementation of functional non-regression tests can be part of the DOD.


08:24 pm January 23, 2024

It sounds as though somebody has an idea of how the product might be tested and documented, and therefore of its quality. These are all matters to consider when formulating a Definition of Done.

04:58 am January 24, 2024

DOD is a critical for Scrum Team to connect with stakeholders. 

07:37 am January 24, 2024

Thanks for your answers, 

I'm looking to link a BDD implementation with the DOD in order to set up a quality assurance cell within the project I'm working on.

08:37 am January 24, 2024

What will that cell be accountable for? Shouldn't the Developers be accountable for meeting the DoD and for quality assurance?

12:58 pm January 24, 2024

Thanks for your feedback,

You're right: developers are obliged to comply with the DOD. In this project, there's no DOD formulated, and there's no QA plan established either.

I'm a junior QA manager, and this is my first job. Before that, I was a developer for 2 years on another project.

The current project has a huge technical debt. Without going into details, I'm trying to set up a quality unit with another colleague. For the moment, we've identified the following action points:
- implement a behavior development approach
- make stakeholders aware of the benefits of a QA plan in an agile context (BDD)
- create e2e tests on nominal cases and extend a test plan to other types of test
- create documentation that's not too wordy and transparent: I've already started (overview of the BDD approach, technical audit of the debt in progress, test plan solce).
- Developers are underwater, I'd like to help the Scrum Team create a DOD

06:05 pm January 29, 2024

As someone that has spent at least half of my career in Software Quality Assurance at various levels, here is my opinion.

If you look at the "testing pyramid" (yeah, old school but still effective) you will see that the majority of all testing is done at the unit, system, and integration level.  Those tests should be simple to create, easy to maintain and provide valuable feedback. If you feel that there are quality issues, that is where you should focus first.  Have Quality Assurance Engineers work with the Developers to understand how to test so that the Developers can write effective unit tests.  Those tests are the quickest to write, simplest to execute and give immediate feedback to developers.

Going with the approach of building BDD documentation like you describe is going to add a level of administration and oversight that will lead to slower delivery and possibly reduced value delivery. Sure, it fits in the traditional Quality Assurance models but it does not provide effective results in the modern age of adapting to change, possibly even multiple times an hour.  

The current project has a huge technical debt. 

Is this technical debt represented in the Product Backlog?  It should be.  The Product Backlog is a representation of all work that is needed to improve the product.  Technical Debt, by definition, lowers the value of the product being produced.  The work to remove the technical debt provides value to the product and stakeholders.  It should be represented in the Product Backlog and managed just as new feature work is.  Weigh the value provided by addressing an item in the Product Backlog without regards to whether it is new feature work or technical debt.  All items provide value. Work on the ones that provide the most value first.

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.