In 2001 Ron Jeffries coined the 3Cs acronym[1]. 22 years later it is still more then current and relevant, especially in a Scrum context, even though it originated originally in eXtreme Programming.
Card, Conversation, Confirmation
Card
The card can be either a physical card or a ticket in an electronic tool. It is the place where the Scrum Team writes (a strategic Product Owner delegates much of the work to the Developers) down all the relevant information for a Product Backlog item.
Scrum Guide:
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Conversation
This is where the Scrum Team and even stakeholders talk about the anticipated objective of the Product Backlog items in regards to the anticipated Sprint Goal. How success is defined, what is important, what needs to be considered, what has to be done, what must not be done; often described as acceptance criteria. The insights of the conversation(s) are written on the card. In Scrum, this would usually happen during refinement.
Scrum Guide:
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Confirmation
Confirmation has several tiers, ensuring that the created increment is releasable and provides value.
Tier 1:
All the acceptance criteria have been fulfilled, best if some of your users perform the acceptance testing. In an advanced state Product Backlog items would subsequently be verified and validated through test automation (think Continuous Integration based on TDD and Specification by Example)
Scrum Guide:
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.
Tier 2:
The Definition of Done (describing releasable) is fulfilled. Best done as a pair of developers to make sure no corners have been cut.
Consider Tier 1 as an implicit part of the Definition of Done.
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.
[…]
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.
Tier 3:
The Product Owner accepts the work during the Sprint, thereby making it potentially releasable.
Scrum Guide:
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.
Only work which fulfills tier 1, 2 and 3 can be demonstrated in the Sprint Review. You can consider the work as Done from the Scrum Team's perspective.
Scrum Guide:
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.
Tier 4:
The Scrum Team makes the work of Scrum Team transparent to all stakeholders. It is about creating full transparency. If there is pushback for any work (PBIs) completed, the work moves back into the Product Backlog.
Scrum Guide:
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.
From Card to Confirmation. The shorter the time frame (think about 2 Sprints) the more you focus on customer value with vertical slices of functionality - Moving away from a project to a product mind-set.
[1] https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/