DoD with 20+ items on the list. That’s too much to expect any team to complete for EVERY story in EVERY sprint, consistently. This can happen for a variety of reasons and it basically comes down to lack of trust
Quite often these lists reflect what QA or a Management THINKS are things developers do to create good software and quite often their perceptions are dated (older programming languages, haven’t evolved) and therefore the team is burdened with a long DoD list of the WRONG THINGS. A lot has changed about how we write software since Java/.Net in the late 1990’s. Unfortunately, in so many companies, DoD hasn’t kept pace.
In the initial sprints for certain teams, there is adherence to DoD. But as soon as work falls behind plan, someone declares forgiveness on DoD (code reviews are usually the first casualty) and the quality of the work starts to drop.
Some organizations adopt a weak or low bar for their DoD. Some focus on documentation and not on the qualities and practices that make great software. Some organizations don’t want to make the developer “feel bad” so give them credit for incomplete software that is barely unit tested. All of these situations result in poorly written code that often fails during later stages.
All too often when asked to see a team’s DoD someone pulls out an Excel spreadsheet on their laptop. Or a PPT slide with tiny font or goes on for several slides. When asked how these are tracked, one would get answers that range from “The Scrum Masters know” to (my personal pet peeve) “We create a template story with each item in DoD as a task” (must then be manually closed by a hapless ScrumMaster because the team members refuse to do that much administrative work).
This talk explores on the world of DoR and DoD and puts in a color that would help meeting the quality standards and upgrading the DoD as we mature along the way