Why only Done PBI can be shown in Sprint Review?

I think you've answered your own question. Having to tell stakeholders such a thing would be an attempt to compensate for reduced transparency, caused by a failure to achieve Done for work shown.

In my opinion, we should not cherry-pick one sentence and focus on it alone disregarding the big picture. Let's take a look at what we can put on the table to understand it better 🙂

"Sprints are the heartbeat of Scrum, where ideas are turned into value." ~SG 2020

"The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created." ~SG2017

Notice that description, or we can say the purpose of the Sprint brakes up with the Increment, it is no longer linked directly. It is the same case for the purpose of the Sprint Review:

"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. (...)" ~SG2020

"A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. (...)" ~SG2017

What we can find about Increments:

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

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done." ~SG2020

"The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done", which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it." ~SG2017

Bolded sentences, in my opinion, are important in this discussion and are essentially the same. However, the biggest (at least editorial) update is in the area of Definition of Done from which you take the sentence in question, lets take a look at the whole part:

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

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.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done." ~SG2020

Consider this chain of events: PBI meets DoD -> (The moment a Product Backlog item meets the Definition of Done, an Increment is born) -> small Increment just born -> Now it is time for Sprint Review and -> (The sum of the Increments is presented at the Sprint Review)

So what happens when PBI does not meet the DoD (thus "cannot be ... presented at the Sprint Review")?

IMHO It simply means that as PBI does not meet DoD it is not an independent Increment or part of another Increment, and therefore it cannot be presented (as part of the Increment[s]) at the Sprint Review.

However, it is not the whole picture, above I briefly highlighted that the current Sprint and Sprint Review description broke the direct link to the Increment, so how to deal with that?

I would say, that now the Increment(s) are semi-linked with the Sprint Review as "results of work":

"(...) The Scrum Team presents the results of their work (...)"

We can also notice that in each of these cases there is used word present, but it is not interchangeable with Inspection, and the results are not the same as the outcome, which also is mentioned.

I would argue that even not Done PBI creates some results, and therefore results of that work can be presented (and inspected) during the Sprint Review, but someone can say that in SG it is written to not do that, so let dive deeper :)

What happens if PBI is not Done? Answer: "Instead, it returns to the Product Backlog for future consideration". and now with the Product Backlog we have a new concept of the Product Goal:

"Commitment: Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal." ~SG2020

When we take one more time a look at the Sprint Review description, we can find this sentence:

"(...) progress toward the Product Goal is discussed."

So, summing this up: When PBI is not done -> it returns to the Product Backlog (for future consideration) -> and during the Sprint Review it is inspected as "progress toward the Product Goal" or simply as part of the Product Backlog.

This part of SG2020 about Sprint Review also IMO supports the above:

"During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."

At the end of the day, you can "defend" the argument that not Done PBI also should be at least considered as results to inspect one way or the other. What is more important in my opinion is to understand how this will impact Transparency in your context as "(...) Inspection without transparency is misleading and wasteful", or Scrum Values, such as Openness and Courage.

I often like to ask (or advise) this: What should you present and inspect during the Sprint Review with your stakeholders, so that the upcoming Sprint and Sprint Planing can be more effective?

If inspecting not Done PBIs can help you make better decisions, then do just that, but remember to be Open and have Courage to notice that it is not Done, it is not part of any new Increment, to take care also about Transparency.



Another thing is if you focus on presenting not Done PBIs only to show how much effort and work you put in last weeks, that you were busy etc., then, in that case, you have some impediments to resolve 🤷🏻‍♂️

Hope this helps 😉

The statement that a Product Backlog Item can only be presented at the Sprint Review was added in the November 2020 revision of the Scrum Guide. Previously, the Product Owner would explain what Product Backlog Items have not been Done and the Developers (previously the Development Team) would discuss problems that they ran into, and these, among other elements, would be used to collaborate with the key stakeholders on what to do next.

Since the Scrum Guide also says that the Scrum framework "is immutable" and the result of implementing parts of Scrum results in "not Scrum", if you were to make the decision to present Product Backlog Items that did not meet the Definition of Done, you would no longer have Scrum and should no longer describe your team's way of working as "Scrum".

However, you should not be constrained to Scrum. The team should own their way of working and should feel free to make decisions that they feel are best. If the team evaluates the risks and rewards of demonstrating Product Backlog Items that are not Done and decides to show or discuss them, that is the team's decision. Depending on the stakeholders, there may be risks in the stakeholders moving forward with the other aspects of the Sprint Review or even leaving the Sprint Review with an unclear understanding of the state of the product. However, the benefit of getting feedback and using that feedback to adjust the Product Backlog and the next steps for the product may outweigh the risks.

Personally, I feel that this was one of the detrimental changes to the Scrum Guide. One of the objectives was to make the Scrum Guide less prescriptive. This change, however, makes the Scrum Guide more prescriptive. It is a good example, though, of why you shouldn't tie yourself to a framework. It's good to be objective and understand the rationale behind different choices and doing what makes sense for your team and organization in the current context.

At the end of the day, you can "defend" the argument that not Done PBI also should be at least considered as results to inspect one way or the other. What is more important in my opinion is to understand how this will impact Transparency in your context as "(...) Inspection without transparency is misleading and wasteful"

Indeed, if the item is on the Product Backlog, it may be inspected in that context; because being able to inspect the Product Backlog is essential to being able to adapt it.

It might be prudent to present this as some kind of prototype / proof-of-concept, rather than anything that may falsely appear to be part of a "Done" increment.

@Simon Mayer What is also worth to think of is that each sprint may vary in its "composition", i.e.: you can have more UX related work, such as experiments and their results you may want to Inspect during the Sprint Review. However, most likely PBIs related to such initiatives may not fit as part of Increment per se and by that not fit into DoD. I think that approaching it even from the PSU point of view only strengthens the argument that you simply not present not Done PBIs as part of the Increment(s), but still, you may want to inspect them as "result of work" or part of the outcome of the Sprint during the Sprint Review.