"If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review "

"PBI acceptance criteria" is how we know that a particular PBI delivers the value as expected. 

"Definition of done" is how we know that everything needed to make that PBI "releasable" is performed. "PBI satisfies acceptance criteria" may be one of the elements of DoD. 



Next will be an oversimplification but try to think of that as "using acceptance criteria we make sure that the customer gets the functionality (value) they expected". At the same time "using DoD we make sure that all necessary works are done, including those that aren't visible to the stakeholder and so no technical debt is created". 



Example of acceptance criteria "the login form does not accept an empty user name"

Example of DoD element "all code must be validated using static analysis tool XXX for known vulnerabilities". 



Of course, when you have three PBI in the project one is supposed to run on Linux, one is supposed to be carried on an airplane and the last one is about digging a hole in the backyard - DoD will be different. But, in reality, for most projects, there is a very limited number of "kinds of PBI" (actually just one :-)) especially if you do a feature team, so it is possible to state common requirements for all items. 

Is the new guide precisely indicating that the DOD must be applied to the PBI level ? 

Yes, since the work done in satisfaction of that PBI must be of sufficient quality to allow the Increment to be used. In other words, the DoD must assure that each selected PBI does not compromise the standard necessary for the Increment to be released.

Where usability of the Increment demands the integration of multiple PBIs, the DoD must assure that such integration occurs.

If a PBI does not meet this standard then it cannot feature in the Increment. 

Is the new guide precisely indicating that the DoD must be applied to the PBI level? 

IMO No. The DoD Commitment is linked to the Increment, not to the PBI per se. I can imagine scenarios where multiple PBIs are needed for Increment, and where only one is needed. In the first case, DoD should be fulfilled jointly by those PBIs, in the other scenario, one PBI needs to address DoD.

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

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

I can even imagine PBIs that do not fit into DoD and the Increment if it won't be oversimplified. Think about research that is deeply talked about during the PSU - i.e Wizard of Oz experiment.

Recently there was not the forum a similar topic that inspired me to wrote an article - hope you find it helpful.

Thanks for your replies. My takeaway from your feedbacks  -> PBI can be set to done if it meets the acceptance criteria as defined. But if this PBI needs to be part of an increment or is an increment itself then must adhere to DOD which makes sense.

"If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review "

As per me this statement seems to be implied in context of an increment only, otherwise I would ask myself why cant a PBI not part of an increment/meeting DOD cannot be presented to a Sprint Review ?

If a PBI meets a certain level of Done (e.g the acceptance criteria of a user story), but it is not yet integrated into the Increment, then it is not Done. Presenting that PBI in a Sprint Review would obfuscate transparency over the Increment, since not all of the work shown would be in a releasable state.

@Ian, It will be against transparency only if you present it like a part of the Increment. Purpose of the Sprint Review is not to focus only on the Increment. 

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

Outcome and results of work are much broader term to consider. What is worth to notice is also that purpose of the Sprint changed:

Sprints are the heartbeat of Scrum, where ideas are turned into value.

2017 version of Scrum Guide put more focus on the Increment, but currently it is no longer the case, it vanishes from description of the Sprint and Sprint Review.

Also, PBI may be done, but Increment may not be Done. If PBI is Done, then Increment is born. However, work needed for Done Increment may be splitted across multiple PBIs thus only when all will be done, a Done Increment will born. It is not 1:1 ratio where each PBI = Increment.

We can distill also from the Scrum Guide the focus on creating valuable useful Increment during the Sprint, as this is nature of Scrum, or we can say tactic:

Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

the Increment is scattered and mentioned across different parts, as we want to turn ideas into value in incremental fashion.

Nevertheless, creating Increment is not the purpose of Sprint, nor the purpose of Sprint Review is to inspect it. It is there, but not as a main character on the stage.

During the Sprint our purpose is to turn ideas into value, it does not matter if we create one Increment, or 100 Increments. It also does not matter if we release them throughout the Sprint duration or not. Whatever tactic we decide to employ, in the end we want to inspect outcome of the Sprint, results of our work and progress towards the Product Goal.

Increment or sum of Increments are one of many results of work that we could have. For example, conducting Wizard of Oz experiment may not lead us to creating useful Increment, but still creates some inspectable results of that work that you may consider inspecting during the Sprint Review.

It will be against transparency only if you present it like a part of the Increment. 

Any encumbrance to clarify what is (and is not) part of the Increment would obfuscate transparency. Hence undone Product Backlog items may not even be presented at the Sprint Review.

I do not understand how you came to such conclusion. To take care about Increment Transparency you must be clear about what is included in it, and ppl involved must understand what Done means. If it requires clarification, so be it, the reason why ppl communicate is to understand each other, that won't magically happen on its own.

Also you are focused only about Increment, which is not sole inspecting purpose of the Sprint Review.

The whole paragraph with that sentence in question is:

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.

It may be clue that it means that not Done PBI means:

• PBI not meet the Definition of Done
• PBI can not be released as part of the Increment
• PBI can not be presented at the Sprint Review as part of the Increment

But, even if we go that strict route that you display, there is a guidance what happens to not Done PBI:

Instead, it returns to the Product Backlog for future consideration.

And in the context of Sprint Review:

The Product Backlog may also be adjusted to meet new opportunities.

It is still inspectable as part of the Product Backlog, as inspection is prerequisite to be able to adjust or adapt something. Presentation on the other hand may be necessary as part of such inspection.

One way or the other you may present and inspect so called not Done PBI, or rather I would say result of work on it.

If you are able to write why you should inspect only Increment at the Sprint Review, despite not mention of that in the Sprint Review description, I would love to read your reasoning.

My take is that the Increment is not an outcome of the Sprint, is one of results of work during the Sprint that impacts it's outcome. The Sprint Review purposeful not mention the Increment and only highlights broad terms such as outcome and results of work, because it is up to the Scrum Team what to present and inspect. This decision could impact i.e. their ability to adapt Product Backlog and impacts their ability to craft right Sprint Goal in upcoming Sprint Planning.

If Scrum Team decides to present not Done PBI (or rather results) and inspect results of current work on it (i.e current designs that grasps their idea) that is fine, it is up to them.

When that happens, they should be clear that it is not part of any Increment, so that they take care about Increment Transparency.

To add something from my experience, each time when Scrum Team shared and inspected also current results of not Done PBIs, when we knew that most likely we will continue working on those PBIs, it helps us to address feedback from stakeholders that were not available all the time during the sprint, thus not wasting that opportunity for collaboration with them.

When we done that, we always were crystal clear that what we inspect now was not part of the Increment and it never ended with misunderstanding, nor obfuscated transparency.

The words used in the Scrum Guide have been chosen very carefully, and without recourse to sophistication. The best advice I can give is to weigh the following in that spirit:

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.

While I agree with you that words used in the SG were chosen carefully, I can not agree to cherry picking of one sentence and extrapolating it on the whole guide with disregard to other sentences, paragraphs and concepts.

That quote is nested in:

> Artifacts

>> The Increment

>>> Commitment: Definition of Done

But somehow IMO here we try to elevate it to the level of Sprint Review concept and recreate its purpose, which is clearly stated with purposefully general words usage:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

As much as words were chosen carefully, placement of sentences were also.

From words point of view, whole part about Sprint Review is silent about PBIs, or Increment, and it is like that on purpose. Even if we take sentences literally, not Done PBI cannot be presented, but that does not equal to that your work effort don't have results of work that you may want present, I can easily imagine situation where you have not Done PBI and bunch of result of work on it to inspect - simple new finding / knowledge is result of such work that may be inspectable and impacts further effort.

Even if we take sentences literally, not Done PBI cannot be presented, but that does not equal to that your work effort don't have results of work that you may want present,

I would suggest that it does, and that the words:

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

have been chosen carefully to avoid ambiguity on the matter. Product Backlog Items that are not Done cannot be presented at the Sprint Review. There are no exceptions.

Efforts to conjure the Guide into saying things it does not say -- or the opposite of what it says -- are unlikely to prove rewarding.

Thanks @Piotr & @Ian for adding your insights.

I somewhat agree with @Piotr regarding the outcome of Sprint Review. I can relate to a situation in my previous company where we had OKRs (Product Goal). We sometimes do had sprints with PBIs to create a draft version of a feature or a testable version of a feature in order to have it inspected with all our stakeholders and adapt it further. These were "not Done" PBIs of course , but in order to create an increment intermediate inspection was necessary. Since these PBIs needed some amount of work which consumed big capacity of a Sprint , to organize this inspection any other time was hard. Best opportunity was Sprint Review where we had most of our stakeholders who could provide valuable feedback, of course after inspecting our increment. 

But if we don't inspect the intermediate outcome or results at all of these PBIs with stakeholders & only focus on Done PBIs, will it impact transparency or lost opportunity for inspection ? I think yes , question is when to do this ? As per me whenever it is deemed right to do it , be it Sprint Review for that matter if the space allows. 

I think that it is at that point where no one will convince the other. Your argument and focusing only on one sentence without looking not only at the tree but also at the whole forest is something that I can not grasp. For me, it is an oversimplification that impedes the context.

IMHO to understand fully the idea behind it is required to also look at the placement in the text and how it connects with other parts. Done or not Done PBI is not the result of work per se, the Increments or Increments are such results (when PBI meets DoD, the Increment is born), like any other tangible thing, such as new knowledge, findings from experiment, designs, or sketches, etc.

My advice is to take some time, and reflect upon the words that are actually used in the Scrum Guide. Should a need ever be felt to mitigate the force of a statement, there is likely to be an opportunity to learn something new.

On this occasion the authors have expressly stated that something cannot be done. It is one of only two occurences in the Guide where the word cannot is used. I would submit that the authors mean exactly what they say, that it reflects accountabilities, and that our efforts ought to lie in achieving the discipline needed to understand and apply this standard.

The definition of done is a formal description of the state of the Increment and not of the PBI and so the scrum guide says that "Work cannot be considered part of an Increment unless it meets the Definition of Done". 

Back to the question, I believe a PBI can be presented at the Sprint Review but you first need to think why and how it is helping you to inspect the outcome of the sprint, how is it making the outcome more transparent and last but not least how is it helping the scrum team to adapt and get closer to the product goal. If it helps what was said before do it, if not reflect and improve.

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.

What is meant by the word 'presented' here?

The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

This line implies there is more to the Review than just 'presenting' work. 

Perhaps discussing what was learned about not-Done work may be considered, particularly if it's as a result of a change to their environment, when adapting the Product Backlog?  

What is meant by the word 'presented' here?

I interpret that as "being presented as a topic for discussion".  It doesn't mean "presented in a demo".  There are times that something will be discussed in a Sprint Review that does not lend well to a demo such as a change to a backend job that does some batch processing. 

This line implies there is more to the Review than just 'presenting' work.

There is much more than presenting work.  The opening paragraph of the Sprint Guide's section describing the Sprint Review states:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

Presenting is just a small part and it is done for the purpose of invoking meaningful discussions. If those discussions do not occur, then the Review is not serving the purpose of empirical analysis.