Skip to content

Commit

Permalink
XS✔ ◾ Stories - Replace with PBIs in Sprint Review rule (#9484)
Browse files Browse the repository at this point in the history
Replaces 'stories' in Sprint Review rule.
  • Loading branch information
ncn-ssw authored Oct 25, 2024
1 parent 150f1a4 commit 1707489
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions rules/what-happens-at-a-sprint-review-meeting/rule.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,27 +17,27 @@ created: 2010-05-06T02:07:33.000Z
archivedreason: null
guid: 863b6968-c082-4413-b90d-d68e0211adc5
---
This is the meeting where the Product Owner accepts or rejects the stories in the Sprint and the Sprint itself.
This is the meeting where the Product Owner accepts or rejects the Product Backlog Items (PBIs) done in the Sprint.

<!--endintro-->

The Team, having [prepared](/meeting-do-you-know-what-to-prepare-for-each-meeting) for the meeting, presents the stories to the Product Owner.
The Team, having [prepared](/meeting-do-you-know-what-to-prepare-for-each-meeting) for the meeting, presents the PBIs to the Product Owner.

One person, often the Scrum Master, presents a summary to the Product Owner of the stories committed at the Sprint Planning meeting and the stories being presented for acceptance.  The Team seeks to have more stories accepted than originally committed.  It is important that the Product Owner knows at the beginning whether The Team believes that they have over or underachieved the Sprint Goal.
One person, often the Scrum Master, presents a summary to the Product Owner of the PBIs committed at the Sprint Planning meeting and the done PBIs being presented for acceptance. The Team seeks to have more PBIs accepted than originally committed. It is important that the Product Owner knows at the beginning whether The Team believes that they have over or underachieved the Sprint Goal.

Each story is then presented by the Team for acceptance. They aim to get the Story accepted as quickly as possible ([aka tick and flick](/tick-and-flick)) while being totally transparent, which includes declaring whether there are any known outstanding bugs (which should already be on the Product Backlog) and adherence to the Team's Definition of Done.
Each done PBI is then presented by the Team for acceptance. They aim to get the PBI accepted as quickly as possible ([aka tick and flick](/tick-and-flick)) while being totally transparent, which includes declaring whether there are any known outstanding bugs (which should already be on the Product Backlog) and adherence to the Team's Definition of Done.

`youtube: https://youtu.be/L94TEsTuLz4`

**Video: Explaining a PBI to a Product Owner with Jake Bayliss (5 min)**

**Note:** If there are additional stakeholders, make sure they are also in the loop and [up to speed on the current increment](https://www.linkedin.com/posts/scrum-trainer_scrum-agile-activity-6815396232366837760-Mhnb/).

If a Story is accepted, but more work needs to be done, a new Story to cover this work is added to the Product Backlog.  Similarly, if a bug is found during the review, it is added to the Product Backlog.
If a PBI is accepted, but more work needs to be done, a new PBI to cover this work is added to the Product Backlog. Similarly, if a bug is found during the review, it is added to the Product Backlog.

If a Story is rejected and returned to the Product Backlog but the Sprint itself is accepted, then a careful decision needs to be made.  If changes have been checked-in to the Sprint's branch then it must be established that these changes have no adverse effect or they must be carefully undone before the branch is merged with the trunk.  For this reason, it is always safer to accept stories with conditions rather than reject them.
If a PBI is rejected and returned to the Product Backlog but the Sprint itself is accepted, then a careful decision needs to be made. If changes have been checked-in to the Sprint's branch then it must be established that these changes have no adverse effect or they must be carefully undone before the branch is merged with the trunk. For this reason, it is always safer to accept PBIs with conditions rather than reject them.

The Scrum Master keeps the meeting on track and to the Timebox by disallowing discussions not relevant to the acceptance or rejection of the story; this is often done by making a note to bring the subject up again in the [Retrospective](/do-you-know-what-happens-at-a-sprint-retrospective-meeting) Meeting.
The Scrum Master keeps the meeting on track and to the Timebox by disallowing discussions not relevant to the acceptance or rejection of the PBI; this is often done by making a note to bring the subject up again in the [Retrospective](/do-you-know-what-happens-at-a-sprint-retrospective-meeting) Meeting.

This meeting is normally timeboxed to as many hours as there are weeks in the Sprint.

Expand Down

0 comments on commit 1707489

Please sign in to comment.