Multiple DoD's based on ticket type

Last post 07:35 pm May 20, 2022
by Daniel Wilhite
5 replies
03:19 pm May 17, 2022

I joined a Scrum Team as a Scrum Master and instead of a single Definition of Done, they have a list of several (nearly 10) DoD's which are linked to different types of issues (User Story, Task, System Test story, Bugfix, Hardware setup, etc).

I am not an expert in DoD's, but I feel like it should be one single list of items that need to be completed for an abstract piece of work to be considered done. I feel like having many lists makes us more confused about what it really means to have something Done, as often the tickets cross different areas. And also because the list is so big I feel like we give it less importance and we tend to never touch it.

What's your take on this matter? Have you ever worked with different DoD's that are related to different types of work?
And if it is indeed better to have a single list, how do you make it so that it is valid for all of them?

Thanks for your advice!

05:55 pm May 17, 2022

The Definition of Done is a commitment associated with the Increment. There must be a DoD which assures that each will be of usable quality. The Increment, after all, is the thing that's actually going to be put into use. There ought to be a clear Product, the value and quality of which can be assured.

That doesn't mean that a DoD has to be an atomic and monolithic construct which is evaluated at the end of an Increment's development. A DoD can be broken down to different levels, bearing in mind that the best way to inspect and adapt is as closely as possible to the time and place of work being carried out.

In other words there can be multiple levels of Done, each of which allows any issues to be identified and dealt with as quickly as possible. For example, the acceptance criteria of User Stories are often thought of as representing Story Done. Any issues can be resolved prior to their integration, and the DoD for the Increment significantly de-risked.

What then is the Increment in your case? Is there a clear Product, the value of which ought to be maximized Sprint by Sprint and its quality assured?



02:59 pm May 19, 2022

Thanks Ian for your reply. Yes, we are building a clear Product, the value of which ought to be maximized Sprint by Sprint and its quality assured. Our increment is this product with any functionality, bug fix, etc that we can get done. Wouldn't any Scrum Team answer this way?

I understand then that from your experience, if it makes it easier for the team to have separate DoD's that reflect better the different types of work we encounter, it should be like this. Did you ever face a situation like it? If so, did you have any downside with respect to having a single one?

03:17 pm May 19, 2022

If you have separate Definitions of Done for various items of work, how would they then be integrated into a Product Increment?

You may reasonably have different levels of Done for an Increment, but ultimately the work being undertaken must be integrated so the commitment to Done for that Increment is assured. Integration and integration testing might thus be included as Definition of Done criteria.

12:31 pm May 20, 2022

Sorry I realise now that I misunderstood your first comment. You were not talking about separate DoD's, you were talking about different levels of Done. So one DoD, not separate ones.

If you have separate Definitions of Done for various items of work, how would they then be integrated into a Product Increment?

Well, we check the DoD of the type of work we want to close and based on this we would take some actions so that it can be considered done. Some things only apply in some cases, that's why multiple DoD's were created.

07:35 pm May 20, 2022

Does every item you work on product an Increment as defined by the Scrum Guide

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

The Definition of Done applies only to the Increment.  If every item you have does not create an Increment, then you should not be applying a Definition of Done to them.  What I see typically is that each item will have some level of Acceptance Criteria provided that will let people know when they have completed that work.  The Acceptance Criteria is usually unique for each item.  Then a single Definition of Done is applied to all items regardless of "type".  This will help identify if an Increment has been created.

It is not unusual for a Definition of Done to have some conditional criteria.  For example a configuration change will not be the same as a new feature.  I have seen the phrase "when applicable" in many a Definition of Done.