During the iteration review, the team demonstrates what they built.
But an iteration is more than just a demo.
In this video, let's look at a good agenda for effective iteration reviews.
First, welcome everyone to the meeting and share any rules or guidelines for it.
For example, it may be necessary to remind people to be polite and that it's fair to criticize the implementation of a feature,
but not to insult those who built it Participants can say a feature is unnecessary or worthless, but should not say that was a stupid decision.
In other cases, you may want to ask participants to refrain from sharing their opinions on a future until that feature has been fully demonstrated.
The second step in the agenda is to say what will and will not be demonstrated.
An Agile team does not need to demonstrate everything it did during the iteration.
The goal of an iteration review is collect feedback.
If no feedback is needed on something, save everyone some time and don't show that thing.
I like to prepare a list of all the product backlog items that were brought into an iteration.
For each item, I'll show its estimate, whether or not it will be demonstrated, and a brief comment on its status.
It's smart to email this list to everyone the afternoon before the iteration review.
Participants can then use it to decide whether they should attend.
The third item in the agenda is to demo the new functionality.
This is the heart of the iteration review, and it may be the only part of agenda you're currently doing.
During this portion of review proceed down the list of items from the prior step.
Keep in mind that the purpose of this review is solicit feedback.
There's no hard rule about who gives the demo.
I prefer to have team members demonstrate items they've worked on.
This gives multiple people a chance to demo and show off their work during one iteration review.
However, if you anticipate a difficult review or harsh critiques, consider having the product owner demo those features.
Experiment to find the plan that works best for your team.
The fourth item on the agenda is to discuss any problems or opportunities that arose during the iteration.
If stakeholders were slow to respond to emails during iteration, now is the time to inform them how this affected the team.
if a team member was out sick for a week and that might affect the overall delivery, discuss that.
Next, the product owner should share which items are currently at the top of the Product Backlog.
Unless things change, these will be the items the team works on immediately.
If stakeholders believe anything they saw during their review affects priorities, this is their chance to convince the project owner to make a change.
Or if the team has completed more or less than anticipated, this is the time to discuss adjusting plans for an upcoming release.
I generally caution product owners against making any immediate prioritization decisions based on stakeholder feedback during the review.
There are reasons for this for many.
The product owner may need time think about what was said in the reviews, or the product donor may want to get estimates from the teams about changes that
were requested, and so on.
Instead of making choices then and there, the product owner solicits opinions during the iteration review and then decides on priorities after the meeting.
As a final step, thank everyone for participating.
Consider thanking the entire team for the work of the Iteration.
consider occasionally praising a team member or two who performed exceptionally well during ITERATION.
Remind everyone when and where the next review will be held.
After the meeting is over, be sure someone adds any new items to the product backlog.