### 5.4.3 Guidelines and Participants | Key Participants | Description | |:----------------------------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Team Coordinator (TeCo) | Supports/facilitates - to the extent required by the Agile Team Members (ATeM) – several activities of the ceremony. <br> She will ensure the previously agreed structure of the meeting is followed, as also the time boxes defined. She can guide the wrap-up activity by facilitating the discussion of each relevant Work Item. | | Business Manager (BM) | Consulted about the demonstrated items and new/deleted work items. | | Agile Team Member (ATeM) | Responsible for the setup and execution of this ceremony. She aligns expectations at the beginning. She can deliver the demo or delegate to the Product Owner (PrOw). <br> In that case, she will support the Product Owner (PrOw) by helping the remaining stakeholders going through the demo. She will drive the wrap-up session and will deliver the relative estimates. | | Product Owner (PrOw) | Accountable for the output of the meeting. She supports the execution of the ceremony by providing feedback regarding the demonstrated <br> items (accept or reject according to the acceptance criteria) and helping with the setup of the ceremony when she conducts the demo. | | Architecture Owner (ArOw) | Acts as an Agile Team Member (ATeM). | | Business Implementation Group (BIG) | Consulted about the demonstrated items and new/deleted work items. | | Project Manager (PM) | Informed about the outputs of the ceremony. | **Guidelines** - **Expose the Work Items to the Product Owner in advance** – During the iteration, the Agile Team Members (ATeM) should demonstrate every work item to the Product Owner (PrOw) as soon as it’s ready. By ready doesn’t mean necessarily perfect but good enough to allow the Product Owner (PrOw) to understand it and see if it’s going in the right direction. By the time the work item is demonstrated in the Iteration Review, the Product Owner (PrOw) will be already familiarized with the item and consequently, more comfortable when validating the acceptance criteria. - **Technical work should be demonstrated** – Every item that is part of the Work Items List (WIL) must be demonstrated to the Product Owner (PrOw). However, Agile Team Members (ATeM) tend to forget this rule when they have to build technical work items (enablement work), mostly because they are “invisible” and the acceptance criteria was defined by the Agile Team Members (ATeM). Because this kind of work plays a key role in the overall solution, it’s very important that the Product Owner (PrOw) is not only aware of their existence but also understands its impact in the overall solution. For the sake of transparency, PM2-Agile strongly recommends that those items are also demonstrated during the Iteration Review. - **Keep the demo short and straight to the point** – A demo is not a playground to do random testing (this should be provided during the iteration when exposing work items for the first time). In a demo, the Agile Project Core Team’s (A-PCT) goal is to confirm that a set of items are implemented properly so they can deliver an iteration goal. To achieve this, the demo must be focused only on the items agreed to validate and nothing else. This will keep the Product Owner (PrOw) and other stakeholders focused. Solid facilitation skills and the help of the entire Agile Project Core Team (A-PCT) is important to achieve this. - **Build test cases targeting the acceptance criteria** - To enable short and straight to the point demos, one needs straight to the point test cases. This is achieved by developing test scenarios based on the acceptance criteria that must be validated. This ensure that the time taken during the demo is just the strictly necessary since audience will be focused on what is relevant. - **Embrace change** - 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 and that is essential for the success of the project. If, on the other hand, the business stakeholders keep coming with requests that constantly change the direction of the work being done, that may mean a systemic problem, probably related either with a not so clear vision of the solution or the Product Owner (PrOw) not spending enough time with the team, etc. Whatever is the case, the Team Coordinator (TeCo) needs to step in and investigate. - **Update the Release Plan** – After the Iteration Review is finished, new data related to the velocity of the Agile Project Core Team (A-PCT) will be generated. PM2-Agile recommends reflecting this data in the Release Plan, as it may impact the contents of what is being delivered in the next release. This updated should be done by the Team Coordinator (TeCo) and then communicated to the Product Owner (PrOw). However, if the team has an Iteration Retrospective after the Iteration Review, this exercise can then be done after, since the latest usually contributes with new Work Items to the Work Items List (WIL), which can have an impact in the Release Plan. ![[5.4 RACI Iteration Review.png]]