Mastering Iteration Reviews

The Iteration review is one of the most important events that occur during an iteration. It’s usually conducted as a meeting at the end of the iteration and its key purpose is to ensure that the team is on the right track and continues to learn about the solution by collecting valuable feedback on what was developed during the iteration.

Following the agile principle “Working software is the primary measure of progress”, it’s not a surprise that the core part of this event is a demo conducted by the team where they expose to the business stakeholders what has been achieved during the iteration. And this is great! However, this is also where problems start to surface. By putting the focus on the demo, teams tend to forget that there’s a preparation that needs to be done as also a set of conclusions that need to be taken and a set of actions to be planned as an outcome of the review meeting.

When preparing an Iteration Review, I clearly identify three specific sets of actions that need to be carefully planned. Those are:

• Align/Review Expectations: This is a 10-15 minutes quick presentation to align the expectations of all the stakeholders on the content of the Demo. This includes checking what was committed in the beginning of the iteration against what was achieved, identifying difficulties and risks, etc;
• Demo: Following a specific set of guidelines, either the Product Owner (or a product expert) or another team member, demonstrates the progress achieved by the team for the iteration that it’s about to end;
• Wrap-up + Work Items List review: After the demo, it’s time to wrap-up the conclusions and see how they impact the Work Items List.

The following sections explain with a bit more detail each of the three sets identified above.

Align/Review Expectations

One of the worst things that can happen to a team is to be misaligned with the business stakeholders. Misalignment leads to frustration! Frustration leads to lack of objectivity, which may affect the outcome of the meeting. In order to avoid that, a quick introduction should be made for the sake of transparency (yes! it can be a “power point”), taking no more than 10 to 15 minutes, to address the following items:

• Scope: What were the Work Items that the team committed to in the beginning of the iteration? This will set the starting point for this meeting;
• Achieved: From the scope, what are the items that the team believes it has completed;
• Not Achieved: From the scope, what were the items that the team couldn’t deliver? An explanation can be added and explained a bit more under the topic related to risks, issues, etc. Note: If ia team member is conducting the demo, he can also demo the unfinished items (to collect feedback). It’s important that in the context of the review meeting, you don’t ask the stakeholders to “play” with something that is not ready to be used, as this may cause confusion. Or if you do, make sure they’re completely aware of that;
• New/Dropped Items: This is very important to communicate/remember the business stakeholders, especially if new items were added to the work items list (even if they correspond to technical stuff that needs to be done to support business functionality);
• Difficulties/Impediments/Risks: Quickly identify these items and describe how did they impact the team and which Work Items were affected.

With this quick introduction (which can trigger some questions), the team ensures that everyone is now on the “the same page” about what to expect from the review meeting. We can now say that everyone is ready for the demo!

Please note that this alignment of expectations DOES NOT replace the constant interaction that is needed between the Product Owner and the rest of team! 

Demo

The demo is, on its own merit, the most important moment of the entire review meeting. This is the moment where the team exposes to the business stakeholders and Product Owner the outcome of the iteration that now comes to an end. But in order to conduct a demo, a few things need to be previously agreed (even before the meeting) in terms of facilitation. Those are (but not limited to):

• Single point demo or hands-on demo – A single point demo means that the Product Owner (or another team member) will conduct the demo, while a hands-on session will give the opportunity to the business stakeholders to actually “feel” the system. There’s no right or wrong when it comes to this. The best option will depend on the will and commitment of the stakeholders. It’s indeed always good to have everyone trying what was achieved, though this will require a bigger effort to facilitate the demo, as you need to ensure that everyone is focused on what is really necessary to validate during the entire session;
• Who will be conducting the Demo – If you decide for a single point demo, the Product Owner is a great candidate. Not only he’s empowered to do so but he’s also the key connecting point with the business stakeholders. It’s almost like if the business stakeholders feel that “one of them” is there, ensuring that everything is fine. A team member can also conduct the Demo. This is also a good approach as it frees the Product Owner to provide specific help to a stakeholder that may be struggling to follow the outcomes;
• Decide which test scenarios to use – Depending on the agreement that you may have with the business stakeholders and how will you present the meeting (single point or hands-on), the test cases the team created during development may be used during this review meeting, either by the Product Owner (single point demo) or by the stakeholders (hands-on demo). On the other hand, the business stakeholders may also want to create their own scenarios. If this is the case, make sure that those tests are aligned with the acceptance criteria of the stories, since that’s what will guide the demo. Nevertheless and whatever the scenario is, this should be previously decided so that the meeting facilitator (whoever that is) can help facilitating the meeting.

With these elements properly defined and agreed, you’re off to a good start of the demo.

For each item to be effectively demonstrated, there’s a small number of steps/activities that should be taken into account. This is not rocket science but it requires some discipline. Without that, you’ll struggle get the results you want.

For each item do be demonstrated, you should:

• Identify and describe the item to be tested – The person conducting the demo (no matter if it’s a single point or hand-on) starts by introducing the item that will be demonstrated. This includes the description and the corresponding acceptance criteria. He can conclude with the indication of the several test cases that will be executed;
• Demo the Item – While demoing the item, each test scenario to be executed should be properly identified, including (and this is very important!) the acceptance criteria that the scenario is targeted to validate. This helps the stakeholders to clearly see the usefulness of the tests being made and will give them more confidence when they need to accept the item. Several teams find it hard to accept changes as part of the review meeting process. Not only they are normal but they are actually welcome. That means that the business is engaged in finding the best solution. Of course if the business stakeholders keep coming with lots of requests for changes that have a significant impact, this may mean some lack of understanding of the acceptance criteria or a lack of clear vision (either from the team or from the business). This needs to be addressed by the team with the help of the Agile coach;
• Ask for confirmation of the item – This action is forgotten quite frequently. If all the acceptance criteria are met, the team should ask for the confirmation that the item does exactly what was agreed to. In other words, to mark that item as DONE. If, on the other hand, some acceptance criteria are not met or there are new things to be made, they should be noted and used in the wrap-up and work items list review step to plan the required actions;

These steps should be repeated for each item that needs to be demonstrated. As soon as all the items are demoed, the group is ready to move to the next step: Wrap-up and Work items list Review.

Wrap-Up and Work Items List Review

After the demo is completed, is time to wrap-up on all the items that were demonstrated. This is very important since it will provide invaluable input not only to keep a healthy work items list but also for the iteration planning meeting the will follow when the next iteration starts.

The Product Owner (or equivalent) or a Team Member should go through all the items demoed and for each verify:

• Status: Accepted or not accepted. If not accepted, specify what were the causes (which acceptance criteria was not verified, bug, etc)?
• Is it a new item? Is it an item that will be dropped?
• For the new items, clarification should be asked to the Product Owner and business stakeholders to allow the team to provide a high level estimate. This is very important for the final step of the meeting.

After all the items have been reviewed, it’s time to groom the Work Items List based on the knowledge gained from the review meeting. After all, everyone needed to perform that task is sitting in the same room! This may include the following actions:

• Work Items that did not meet the acceptance criteria – Should they go back to the top of the Product Work Items List, ready to be taken and corrected in the next iteration? Or shall they be postponed for a future iteration?
• New Items in the Work Items List – Product Owner and business stakeholders should provide enough information to allow the team providing some relative estimates (at least). This information may help the business to decide on the prioritisation. Please note that depending on the number of new stories and the feedback received, the team may need to perform the estimates after the review meeting. This is fine, as long as they provide that data immediately to the Product Owner so that he can ensure that the work items list is properly prioritized before the next Iteration planning meeting.

The Final Outcome

When the iteration review is concluded (or a couple of hours after, if the team needs to perform some estimates after the meeting), the team should have a properly groomed and prioritized Work Items List that they feel comfortable to use as the basis for the planning of the next iteration. The success of an Iteration Review is not linked solely to the number of Work items approved. In fact, ensuring that the team collected solid and relevant feedback that will guide them in the direction of the needs of the business stakeholders is, with no doubt, the best indicator of success.