About the DOD
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.
Thanks
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.
DOD is a critical for Scrum Team to connect with stakeholders.
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.
What will that cell be accountable for? Shouldn't the Developers be accountable for meeting the DoD and for quality assurance?
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
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.