Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Definition of Done for different issue types in Jira

Last post 10:14 am December 15, 2021 by Anton Baida
9 replies
10:48 am December 10, 2021

Hi everyone,

I am a little bit confused with the DoD concept and whether it's applicable for increment-only issue types or to all PBIs that team has. For example, in my team we have the following issue types in Jira:

1. Story - for works that will be included in the future release

2. Story (dev only) - for works that act as enablers for future increment-related works 

2. Task - basically same as a regular story, but without describing the needed scope from the user's POV

3. Bug - seems obvious here

4. Spike - for investigating & learning

As you can see from the above-mentioned list, only "Story" & "Task" issue types are directly related to the increment and will be released at the end of the Sprint. Therefore, if we write down in our DoD smth related to testing or user acceptance, it can't be applied to "Story (dev only)", "Bug", "Spike" issues types at all, because it's clear that there is no testing & user acceptance there. 

Am I right to understand that if we decide to create DoD for our team, it should be created only for the increment-related issues? I can't see any other options here for now, unfortunately. 

Please advise what will be the correct way to go here.


07:27 pm December 10, 2021

The DoD comes into play during each Sprint, which means that it affects PBIs present within the Sprint Backlog and not the Product Backlog. 

 

Am I right to understand that if we decide to create DoD for our team

What do you mean IF?  A DoD is essential to ensuring quality and aids in transparency and inspection.  Without one, how will you know if the increment is in a usable and releasable state? 


08:01 pm December 10, 2021

The definition of "Definition of Done" from the November 2020 edition of the Scrum Guide:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

Based on this, the Definition of Done isn't necessarily applicable to an individual Product Backlog Item, but the Increment as a whole.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

I find the wording of this sentence a little confusing. I interpret this as meaning that a Product Backlog Item cannot be considered Done until the Increment meets the Definition of Done. You may meet the Definition of Done PBI-by-PBI or you may take a bundle of PBIs and move them to Done after meeting all of the elements of the Definition of Done.

Given the descriptions of the work that you have, it seems like 4 of the 5 - Story, Story (dev only), Task, and Bug - will lead to some change in the product. Because they will change the Product, they would not be done until the Product Increment meets the Definition of Done.

I'd also point out that the Definition of Done is not an optional element of Scrum. If you are doing Scrum, you have a Definition of Done that the team (or teams, in a scaled setting) are adhering to in order to support transparency and a shared understanding of the work that must be done and the state of the Increment.


08:12 pm December 10, 2021

This is a link to the Scrum Guide's section that explains the Increment. (https://scrumguides.org/scrum-guide.html#increment)   This is also the place where the Definition of Done is explained. Notice that the Definition of Done is the commitment for the Increment.  So it applies to any work done that creates an increment and conveys to everyone, inside and out of the Scrum Team, what it means when your teams says they are "done". 

As @Scott Anthony Keatinge mentions, there is no "if ands or buts" about it.  You need a Definition of Done.  

Related to your post, I am curious if having all of these different types is actually useful?  For example, your Story (Dev Only) sounds like a technical debt place holder.  In the Scrum Guide's Section that describes the Product Backlog it starts with this statement:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

I have found that when you start to treat items differently based upon their purpose, you have a more difficult time managing the backlog.  Technical Debt can be pushed off in favor of delivering new features.  Same can be said for Bugs.  They can get preferential treatment.  In reality, everything in the Product Backlog has two values: negative value as long as it exists in the Product Backlog and positive value when it is addressed.  Treat everything the same and determine actions based upon the value of each item. This can help eliminate any type of confusion on how to deal with each item, i.e. does the Definition of Done apply to this item type. 

The Manifesto for agile software development has one principle that I feel is often overlooked.  Listed 10th from the top or 3rd from the bottom, this principle can make a huge difference. 

Simplicity--the art of maximizing the amount of work not done--is essential.

Stop trying to complicate matters.  Simply the work and processes of doing that work as much as possible.


09:22 pm December 10, 2021

Am I right to understand that if we decide to create DoD for our team, it should be created only for the increment-related issues? I can't see any other options here for now, unfortunately. 

What's unfortunate is that you are looking for other options. The entire point of Scrum is to create a Done increment.


10:40 am December 13, 2021

Hi everyone and thank you for the quick answers.

I'd like to stress that I am not avoiding the creation of DoD by any means, just trying to figure out how to actually put it into practice. Now let me give you an example and explain what puzzles me here.

We just discussed that DoD is a characteristic of an Increment rather than a sprint backlog item. I got it.

In order to produce the increment, we use stories and tasks in Jira. Eventually, we have some bugs that are resolved in order to release the functionality to production, make it "Done".  So when we write down smth like "Code is merged to master branch through pull request." or "Code is peer-reviewed (all comments are fixed/addressed and approved by /OWNER/)." to our DoD, it obviously implies to stories and tasks where the development work is done, but not to bugs. For bugs we'll have something else, that will work for them and will not work for stories & tasks. 

There is a point of confusion for me. On the one hand, all these issue types are increment-related. And on the other hand, it seems to me that we need 1 DoD checklist for stories&tasks and another DoD checklist for bugs.

Please correct me if I am wrong and please give some practical examples. 

 

 


12:01 am December 14, 2021

There is a point of confusion for me. On the one hand, all these issue types are increment-related.

Correct.

And on the other hand, it seems to me that we need 1 DoD checklist for stories&tasks and another DoD checklist for bugs.

Correct.

A Definition of Done can exist at many levels. It must ultimately apply to the increment, and the best way to inspect and adapt increment quality is as closely as possible to the time and place of work being carried out.


04:40 pm December 14, 2021

"Code is merged to master branch through pull request." or "Code is peer-reviewed (all comments are fixed/addressed and approved by /OWNER/)." to our DoD, it obviously implies to stories and tasks where the development work is done, but not to bugs.

So you are saying that the code changes made for bugs are not merged to master through a pull request or peer-reviewed?  Why would that be the case?  How does the team know that the code changes to correct one bug will not introduce many others?  If these items would not apply for a bug, what would you have instead?

This is why I suggested that everything be treated equally.  If you are making code changes that will be deployed to production, they should all be seen and treated equally.  

...it seems to me that we need 1 DoD checklist for stories&tasks and another DoD checklist for bugs.

I disagree. I feel that a single Definition of Done can be applied to anything that is in the Product Backlog, regardless of how you decide to classify them.  Every code change made will find its way into an increment. According to the Scrum Guide:

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Again, simplify things as much as possible. 


05:07 pm December 14, 2021

In order to produce the increment, we use stories and tasks in Jira. Eventually, we have some bugs that are resolved in order to release the functionality to production, make it "Done".  So when we write down smth like "Code is merged to master branch through pull request." or "Code is peer-reviewed (all comments are fixed/addressed and approved by /OWNER/)." to our DoD, it obviously implies to stories and tasks where the development work is done, but not to bugs. For bugs we'll have something else, that will work for them and will not work for stories & tasks.

I don't follow. The two examples that you give - "code is merged to master branch through pull request" and "code is peer reviewed (all comments are fixed/addressed and approved by /OWNER/)" - seem equally applicable to bugs and stories. Why would these not apply to bugs?


10:14 am December 15, 2021

Sorry for the confusion guys, wanted to point out some obviously different criteria applicable only for tasks or bugs but failed miserably ¯\_(ツ)_/¯

Again, thanks everyone for the help, appreciate it.