(classical music)
The Iteration review is a cadence-based event
in which each team inspects the increment
at the end of every iteration to assess progress
and then adjust its backlog for the next Iteration.
During the Iteration review, each Agile team
measures and then demonstrates its progress
by showing working stories to the product owner
and other stakeholders for their feedback.
Teams demo new stories, spikes, refactors
and nonfunctional requirements.
In this short video,
we'll walk you through how you can achieve this
and share tips from enterprises around the globe.
(classical music)
The preparation for the Iteration review
begins during Iteration planning
where teams start thinking about how they will demo stories
to which they have committed.
Beginning with the end in mind
facilitates Iteration planning and alignment,
fostering a more thorough understanding
of the functionality needed before Iteration execution.
Ahead of the Iteration review,
the team should update the status of its Iteration goals.
Agree on the presenter
and order of the stories to be demonstrated.
Prepare any findings and results
required to demonstrate stories.
Make sure the time and location
of the Iteration review is known.
Invite any other stakeholders
who will want to see the team's progress
which may include members of other teams.
Note that although Agile Release Train stakeholders
may attend, their interest and level of detail
are usually better served by the System Demo.
(classical music)
The Iteration review is typically timeboxed
to one to two hours max.
The Iteration review starts by going over
the Iteration goals and discussing status.
It then proceeds with a walk-through
of all the committed stories.
Each completed story is demoed in a working tested system,
preferably in a staging environment
that closely resembles the production environment.
Spikes are demonstrated via a presentation of findings.
Note that many to most stories will have been achieved
during the course of the Iteration
and may already have been demoed,
in which case a quick update may be more appropriate.
Stakeholders provide feedback
on the stories that are demoed
which is the primary goal of the review process.
After the demo, the team reflects
on which stories were not completed, if any,
and why the team was unable to finish them.
This discussion usually reveals impediments or risks,
false assumptions, changing priorities,
estimating inaccuracies or overcommitment.
These findings may lead to further study
in the Iteration retrospective
about how the next Iterations
can be better planned and executed.
As Scrum Master, your job is to keep this process
on track and ensure that the goals are met.
(classical music)
Here are some tips to help you deliver
a successful Iteration review.
Limit demo preparation by team members to one to two hours.
Too much demo overhead slows down the team
and jeopardizes the value of the demo.
Minimize the use of slides.
After all, the purpose of the Iteration review
is to get feedback on working software functionality,
hardware components, and other concerns.
Verify that completed stories meet the definition of done
and have been accepted by the Product Owner.
Demo incomplete stories too
if enough functionality is available to get feedback.
Encourage providing constructive feedback
and celebrating the accomplishments.
If a significant stakeholder cannot attend,
the Product Owner should follow up with that person
to report progress and to get their feedback.
Note that teams that are in flow
with Continuous Delivery and Continuous Deployment
will likely have reviewed and accepted many stories
during the course of the Iteration.
In this case, the review is more like a status
and feedback session than a detailed story by story review.
(classical music)
To recap, remember the Iteration review
serves three important functions.
First, it brings closure to the Iteration timebox
that many individuals have contributed to
in order to provide new value to the business.
Second, it gives teams an opportunity
to show the contributions they've made to the business
and to take some satisfaction and pride
in their work and progress.
And third, it allows stakeholders to see working stories
and provide feedback to improve the product.
For more information, videos, and toolkits
on the role of Scrum Master and SAFe®,
please consult the SAFe® Community Platform and participate
in the SAFe Scrum Master community of practice.
Additional reading on the SAFe Scrum Master role
and Iteration planning can be found
in the articles on the Scaled Agile Framework® website.
- [Narrator] This video depicts the Iteration review
taking place in person which isn't always possible.
For enterprises practicing SAFe with remote
and distributed teams, here are our top recommendations
for a successful remote iteration review.
Update the status of the iteration goals.
Agree on the presenter
and order of the stories to be demonstrated.
Update the team backlog
based on the feedback on the stories demoed.
For more remote support,
please use the Remote Iteration Review Facilitator Checklist
in the Remote ARTs toolkit.
(classical music)