Scribd
Upload
13 views3 pages

Sprint Review

The Sprint Review is an event where the team presents the work completed in the sprint to stakeholders to obtain feedback and collaborate on future work. The team demonstrates the product increment and highlights challenges faced. Stakeholders validate user stories and provide new feedback to optimize product value.

Uploaded by

alina.commerce09
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
13 views3 pages

Sprint Review

The Sprint Review is an event where the team presents the work completed in the sprint to stakeholders to obtain feedback and collaborate on future work. The team demonstrates the product increment and highlights challenges faced. Stakeholders validate user stories and provide new feedback to optimize product value.

Uploaded by

alina.commerce09
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Sprint Review

Overview

Sprint Review is a close collaboration event between the Team and stakeholders, to inspect the
Product Increment (what was done in the Sprint i.e. the team has produced a coded, tested and
usable piece of software) and adapt the Product Backlog, if needed.
Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate
on the next functionalities that could be done to optimize Value. This is an informal event, not a
status meeting, and the presentation of the Product Increment is intended to elicit feedback
and foster collaboration.

Purpose

 See how the Product was improved by the addition of new features, stories and tech
enablers.
 Necessary to optimise the product value. All participants collaborate in identifying items
from the Product Backlog that bring the most value.
 An event when the Team and everyone learn from what has been done/experienced
during the Sprint.
 Outward focused. How can the Team improve the product?
 Collaborate with the Stakeholders to obtain early feedback about the Sprint's Product
Increment.
 An event when the Agile Team learns from what has been done/experienced during the
Sprint. Learn and Respond part of a Product Increment's inspect-and-adapt cycle.
 This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event
is usually shorter. The Scrum Master ensures that the event takes place and that
attendees understand its purpose. The Scrum Master teaches everyone involved to keep
it within the time-box.
 The Sprint Review is intentionally kept very informal, typically with rules forbidding the
use of PowerPoint slides and allowing no more than two hours of preparation time for
the ceremony. A Sprint Review should not become a distraction or significant detour for
the team; rather, it should be a natural result of the Sprint.

How to run the event

During the Sprint Review, the Product Increment and team deliverables are assessed against
the Sprint Goal determined during the Sprint Planning ceremony. Ideally, the team has
completed each Sprint Product Backlog item brought into the Sprint, but it's more important
that they achieve the overall goal of the Sprint.
Sprint Review must encourage the customer to provide feedback on the current product Value
and to adapt and decide on the next improvement(s) that will add the most Value.
The Team will highlight the challenges and the obstacles they encountered while delivering the
current product version.
Client and/or Product Owner will decide if the presented User Stories are “Done” or not.
A preliminary Product Backlog prioritisation takes place during Sprint Review.

Tips for effective Sprint Review

 Pre-review User Story validations are highly recommended, if possible.


 Welcome any feedback, especially from the stakeholders.
 Capture the new feedback as it results in changes that are added as new Product
Backlog item(s).
 Never say "no" outright to a new feature or enhancement request. Always put it on the
Product Backlog (with the appropriate priority).
 Word the new requirements as a request for functionality or request to solve a problem
("the what") rather than a "do it this way" command ("the how").
 The Scrum Master and the Team to work with the Product Owner to make sure that the
right stakeholders are present. Note that the Product Owner is responsible for inviting
the right stakeholders.
 A good KPI for the Sprint Review is how active the stakeholders are. If till the end of the
event the team got no questions at all, they probably made something wrong.
 Present the User Stories from the business value point of view they bring and use less
technical language.
 Provide a good level of context about the source of the request & the need that the user
story addresses, to give clear understanding to the stakeholders.
 Be transparent enough with refactoring tasks and other tasks aiming to decrease
technical debt and explain the reasons why they were not fixed initially.
 Don't present non-disclosed rigged functionality, such as hard-coded values and other
programming shortcuts that make the application look more mature than it currently is.
 Don’t present information that is obvious or brings no business value.
 Don’t present the User Stories that are not done yet according to Definition of Done.
Exceptions can be made only when you need feedback before finalising the User Story.
 The Product Increment review should be on an equipment as close as possible to the
planned production environment. For example, if you are creating a mobile application,
present the features on a smartphone — perhaps hooked up to a monitor — rather than
a laptop.
 Ask for suggestions from everyone (including the Team members) on how to gain more
value from the current and future features.
 A User Story is considered done if the Product Owner and business users confirm that
the acceptance criteria are met.
 As User Stories are completed throughout the Sprint, the Product Owner and the E
Team should check that the product meets these standards. This continuous validation
throughout the Sprint reduces end-of-Sprint risks and helps the Engineering Team spend
as little time as possible preparing for the Sprint Review.
 Reopening of closed User Stories should be avoided. Issues that were not found on time
or regression issues should be logged as new items.
Common pitfalls

This event could became a demo meeting which does not generate any feedback.
Loosing the ideal moment of adding additional value.
Story presentation becomes a full functional testing review.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy