Definition of Done "by the book"

To my understanding, DOD focuses the attention on delivering potentially shippable increments of software at the end of each sprint.

That’s right.

So that would mean that we use it at a US/Sprint level? Correct?

The Scrum Guide doesn’t say anything about user stories. If however a team was dealing with user stories, do you think asserting a level of “Done” for each story might help them to satisfy the Definition of Done for the increment?

To my understanding, DOD focuses the attention on delivering potentially shippable increments of software at the end of each sprint.

So that would mean that we use it at a US/Sprint level? Correct?

Yes.  The Definition of "Done" helps the Development Team know how much work is needed for a Product Backlog item (i.e. user story) and brings transparency to the Increment.  Completing a "done" Increment every Sprint is essential in Scrum.  It is helpful to think in terms of "What if I am only funded for one Sprint, or funded Sprint to Sprint?".

The Scrum Guide helps explain this:

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.

What that means is that if the Product Owner decides to release the product Increment to production, then the Increment is of release quality and there is no more work to be done.  Everyone is on the same page.  There are no integration or hardening Sprints in Scrum - everything must be done within the Sprint time-box.  

Why wouldn't unit tests and automation apply to each product Backlog item (i.e. user story)?

To me, the DoD applies to the Increment being created during the Sprint.  How that is applied is up to the Scrum Team (notice I didn't say Dev Team) to decide and agree upon.  Some of my teams have chosen to apply it at the story/problem statement level.  Others have chosen to apply it at the increment level even when there were multiple stories/problem statements in the Sprint that contributed to the increment.  As long as everyone on the Scrum Team agrees and understands what it means to be "Done" then you are doing right according to Scrum.

I do encourage that teams apply a similar level of understanding at the story/problem statement level so that is widely understood what it means to say a story/problem statement is complete. My preferred method is to have acceptance criteria stated for each story/problem statement that is usually independent of the DoD. 

I kept stating "story/problem statement" because as @Ian pointed out stories are not mentioned in the Scrum Guide. It states this in the Product Backlog section.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

I tend to find that people understand the concept of stories or problem statements to describe the first part of that statement.  Acceptance Criteria help to "name" the last part. 

Hello,

Thank you for sharing your expertise. I am getting a better view and understanding based on your feedback.

My concern is how to apply Scrum in the real world. In most backlogs, you can find US, Features and Epics.

If a US is to be finished in a Sprint, an Epic can cover several Sprints ; (meta-user-story). So if I choose to apply a Definition Of Done, it cannot apply to any PBI, but only to those that can be finished in an iteration, which I translate by US, or any incremental PBI composing any typical Produt Increment to be releasable at the end of a Sprint.

With that being said, I can understand the DOD in the context of finishing (delivering value often). Another way to see it could be : ALL PBI Done for a specific Sprint = Specific Increment Done (fractal).

Jason.

The way I've been practising, DOD never applies to individual PBIs (regardless of their type). Some (most, to be more precise, but not all!) PBIs have acceptance criteria to help everyone understand when a story, for instance, is complete. These acceptance criteria (AC) can be written in bullet points, be part of automated tests, etc, and are specific to each individual story (to continue that line of thought).

Conversely, the DOD is made of functional and non-functional parts that apply at increment-level. More precisely, for the work completed in sprint, everything that's needed to have the work done and to have said work "done" released to a production. Now, if the work isn't released (note the "potentially" - with the PO deciding whether to release or not), the appropriate release steps won't be covered. Under functional you would include something like "code reviews accepted", "regression complete", "relevant code added to main branch", etc; while "documentation, if any, to be updated", "release notes added on app display", "front-end Spanish translations double-checked" would likely be under non-functional.

DoD is something generic. It tells you what the team, or multiple teams, see as a done increment. Not to be confused with acceptance criteria for individual PBIs. DoD is shared across all teams.

For instance: I have included into the DoD that the team has to have questions for the stakeholders at every sprint evaluation. If they haven't thought of that, then it's not Done. 

I'm not sure I fully understand the rationale and/ordesire to include questions for the stakeholders at every sprint evaluation - by the way, what do you mean by this (sprint evaluation)? Review? Retrospective?

To me, the practice (adding such questions to stakeholders added to the DoD) doesn't make much sense. What questions would these be? Related to the increment itself? Regarding future plans? And why exactly would the mere fact of asking questions have an impact of the Done status? Let's say there's your team's DoD in place, with one release every sprint - if coding's complete, UAT passed, regression covered, PO anxiously eager to deploy software to production, documentation (eg internal release notes) updated, where the value in having to address questions to the stakeholders (and not be Done, per the DoD)? 

And anyway, except for the review, stakeholders aren't supposed to discuss with DT, but with the PO. You'd want the PO to be in constant comms, throughtout the sprint, with the relevant stakeholders. Any questions the team (and DT in particular) has for stakeholders can be asked at review; during sprint, questions should be addressed to the PO.

To sum up, in my view, questions for stakeholders have no room on a DoD