Definition of Done for different issue types in Jira

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? 

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.

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.

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.

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. 

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.

"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. 

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?

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.

What about non-code issues, like writing a style guide? It has a different DoD b/c for example, it doesnt go through any testing.... 

DoD is at the Increment level as a formal description of the state of the Increment when it meets the quality measures of the product. Is the style guide part of the Increment? Will it be integrated into the product itself? If yes, DoD would apply. If no, it may not.

PBIs need to meet DoD in order to be integrated into the Increment (product). It is meant as a commitment to quality and stability of product (we are not knowingly introducing something that will degrade our product). It is not the same as PBI specific acceptance criteria. 

My opinion is slightly different than @Ryan's. If your style guide is part of the increment for the product update, the Definition of Done applies.  For example, if the style guide is something that you are releasing to the stakeholders so that they have better understanding of the product and how to interact with it, then the Definition of Done should have some information on what it means to be "done" with the style guide work.  However, if the style guide is only internal to the single Scrum Team, then I would not consider it to be subject to the Definition of Done.  In that case it is part of team agreements on how software is developed and not something that stakeholders need to be aware.  CAVEAT: Not all stakeholders are external to the company. Another Scrum Team that consumes/interacts with your product may be considered a stakeholder and in that case the style guide could be part of your increment.