how_do_we_run_our_first_iteration_demo_or_sprint_review
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
how_do_we_run_our_first_sprint_review [2015/11/17 12:54] – [Guidelines] hpsamios | how_do_we_run_our_first_iteration_demo_or_sprint_review [2021/12/01 09:47] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== How Do We Run Our First Sprint Review? ====== | + | ====== How Do We Run Our First Iteration Demo (Sprint Review)? ====== |
+ | The Iteration Demo (or Sprint Review or ...) is a event where the Team presents information to the (customer especially) stakeholders about the increment of work that was completed during the last Iteration (Sprint) in order to get feedback about that work. | ||
- | ====== Premise ====== | + | A secondary purpose of the Iteration Demo (Sprint Review) is to: |
- | + | ||
- | The Sprint Review is a meeting where the Scrum Team presents information to the (customer especially) stakeholders about the increment of work that was completed during the last Sprint in order to get feedback about that work. | + | |
- | + | ||
- | A secondary purpose of the Sprint Review is to: | + | |
- Provide information on the Release Plan status by showing the results of work that has been completed. | - Provide information on the Release Plan status by showing the results of work that has been completed. | ||
- Show stakeholders that the team is operating professionally and high performance, | - Show stakeholders that the team is operating professionally and high performance, | ||
- | Typically, the Sprint Review is held using tele-conferencing facilities so that everyone who has an interest can attend and so people who cannot attend can use a captured recording of the tele-conference to provide feedback at a later date. The Sprint Review is structured as a small set of “context setting” activities and a series of demonstrations showing the working system just completed. These demonstrations should not be confused with a sales presentation or a training session. If sales or training sessions are needed, they should be arranged in a separate meeting. | + | Typically, the Iteration Demo (Sprint Review) is held using tele-conferencing facilities so that everyone who has an interest can attend and so people who cannot attend can use a captured recording of the tele-conference to provide feedback at a later date. The Iteration Demo (Sprint Review) is structured as a small set of “context setting” activities and a series of demonstrations showing the working system just completed. These demonstrations should not be confused with a sales presentation or a training session. If sales or training sessions are needed, they should be arranged in a separate meeting. |
- | The content of a typical Sprint Review is described in the sections below. This information is relevant in the typical | + | The content of a typical |
- | * A team doing pure maintenance work may not have anything to demonstrate to stakeholders, | + | * A Team doing pure maintenance work may not have anything to demonstrate to stakeholders, |
- | * A team might be working on an Inception | + | * A Team might be working on an Inception |
- | * A team might be working on a final Release work, which for many means that defect arrival rates, for example, might be part of the Sprint Review. | + | * A Team might be working on a final Release work, which for many means that defect arrival rates, for example, might be part of the Iteration Demo (Sprint Review). |
- | Irrespective | + | Irrespective |
====== Guidelines ====== | ====== Guidelines ====== | ||
- | - The basic rule for Sprint Reviews is simple - functionality that isn't " | + | - The basic rule for Iteration Demo (Sprint Reviews) is simple - functionality that isn't " |
- Although the meaning of " | - Although the meaning of " | ||
- If " | - If " | ||
- | - When doing the demonstration “done” might also mean that the demonstration shown using something that is “close to the production environment.” For a product development shop, it might mean something like “Demonstrations should be performed on End-User builds running on a clean machine.” | + | - When doing the demonstration, “done” might also mean that the demonstration shown in something that is “close to the production environment.” |
- | - Be very careful about using a purpose built PowerPoint presentation to structure this meeting. Using PowerPoint (apart from being a potential waste of time generating the slides) typically gives the stakeholders the feeling that this is a more formal presentation, | + | - Be very careful about using a purpose built PowerPoint presentation to structure this meeting. Using PowerPoint (apart from being a potential waste of time generating the slides) typically gives the stakeholders the feeling that this is a more formal presentation, |
+ | |||
====== Structure ====== | ====== Structure ====== | ||
**Duration: | **Duration: | ||
- | **Who: | + | **Who:** Team and Stakeholders especially their customers, management, users and anyone else who might be interested and have feedback. |
**Summary** **Agenda** | **Summary** **Agenda** | ||
Line 40: | Line 39: | ||
* Gather feedback | * Gather feedback | ||
- | **Result:** Feedback captured for the Product | + | **Result:** Feedback captured for the Team (Product) Backlog to be prioritized so that the Backlog is ready for Iteration (Sprint) Planning. |
====== Sample Agenda ====== | ====== Sample Agenda ====== | ||
- | * Product Owner: Review | + | * Product Owner: Review |
- | * Scrum Master: Review Sprint Goals, Sprint Burn-down, and discuss team learning that took place, especially for commitments not met. | + | * Scrum Master: Review |
* Team Members: Demonstrate functionality | * Team Members: Demonstrate functionality | ||
* Stakeholders: | * Stakeholders: | ||
- | * Team Members: Show evidence using artifacts, for example, showing quality measurements | + | * Team Members: Show evidence |
- | * Product Owner: What are we thinking will be in next Sprint | + | * Product Owner: What are we thinking will be in next Iteration (Sprint) |
- | * Scrum Master: Announce planned next sprint review | + | * Scrum Master: Announce planned next Iteration Demo (Sprint Review) |
* Scrum Master: Thank participants | * Scrum Master: Thank participants | ||
====== Checklist ====== | ====== Checklist ====== | ||
- | When setting up the Sprint Review meetings (for the first time or ongoing), it may be useful to have a checklist to ensure a successful Sprint Review meeting. The following is such a checklist: | + | When setting up the Iteration Demo (Sprint Review) meetings (for the first time or ongoing), it may be useful to have a checklist to ensure a successful |
- | ===== Before the Sprint Review ===== | + | ===== Before the Iteration Demo (Sprint Review) ===== |
- | * Set up a recurring calendar event, with virtual collaboration tool (WebEx, Lync, etc) for the Sprint Review. | + | * Set up a recurring calendar event, with virtual collaboration tool (WebEx, Lync, etc) for the Iteration Demo (Sprint Review). |
- | * By convention, the subject line of the email should help people understand the work being looked at. For example, " | + | * By convention, the subject line of the email should help people understand the work being looked at. For example, "Iteration Demo (Sprint Review) – Team name - (Area of Focus)”. |
- | * Participants invited include | + | * Participants invited include |
- | * Customers: The Product Owner is responsible for working arrangements with customer stakeholders. If it is the customer' | + | * Customers: The Product Owner is responsible for working arrangements with customer stakeholders. If it is the customer' |
- | * Management: In terms of feedback provided by management, in addition to direct feedback on the functionality delivered, management should also ask about initiatives that the organization is driving. For example, if there is a renewed focus on “quality” management representatives might ask the team “how do you feel about the quality of the work you have completed? | + | * Management: In terms of feedback provided by management, in addition to direct feedback on the functionality delivered, management should also ask about initiatives that the organization is driving. For example, if there is a renewed focus on quality management representatives might ask the team “how do you feel about the quality of the work you have completed? |
- | * Before the actual Sprint Review meeting the body of invitation for this Sprint Review should be updated with the sprint goal and the sprint backlog | + | * Before the actual |
- | ==== ==== | + | ===== At the Iteration Demo (Sprint Review) Meeting ===== |
- | ===== At the Sprint Review Meeting ===== | + | |
- | + | * The committed | |
- | | + | |
- | * The committed | + | |
* The Team has prepared workstations, | * The Team has prepared workstations, | ||
* This is not a sales presentation, | * This is not a sales presentation, | ||
Line 79: | Line 76: | ||
* Scrum Master records the virtual collaboration session so others that wanted to see the session but were unable to turn up can review it at a later date. | * Scrum Master records the virtual collaboration session so others that wanted to see the session but were unable to turn up can review it at a later date. | ||
- | * The team presents the Sprint results and demonstrates the new functionality, | + | * The Team presents the Iteration (Sprint) results and demonstrates the new functionality, |
* If customers are involved, make sure that functional user stories (as opposed to technical / non-functional or environmental user stories) are demonstrated first. | * If customers are involved, make sure that functional user stories (as opposed to technical / non-functional or environmental user stories) are demonstrated first. | ||
* Demonstrate the story from the customer' | * Demonstrate the story from the customer' | ||
* All stakeholders can provide all types of feedback - comments, observations, | * All stakeholders can provide all types of feedback - comments, observations, | ||
- | * Changes to (or additions of) features may be made to the Product Backlog at this time. (Proposed | + | * Changes to (or additions of) features may be made to the Team (Product) Backlog at this time. (Note: feedback is a series of proposed |
- | * If the team reports an obstacle that is not yet solved, escalate this type of obstacle to management. | + | * If the team reports an obstacle |
- | * Explain what could not be completed during the Sprint and why (for example, the team under-estimated effort, there were interruptions to address critical customer issues, and so forth). | + | * Explain what could not be completed during the Iteration (Sprint) and why (for example, the team under-estimated effort, there were interruptions to address critical customer issues, and so forth). |
===== Additional Reminders ===== | ===== Additional Reminders ===== | ||
- | * Be sure the appropriate proprietary marking appears on any documents / PowerPoint slides used in (or sent out before) the Sprint Review or that the proprietary nature of the material shown in the Review is clearly stated. | + | * Be sure the appropriate proprietary marking appears on any documents / PowerPoint slides used in (or sent out before) the Iteration Demo / Sprint Review or that the proprietary nature of the material shown in the Review |
- | * Make sure the virtual collaboration tool (Webex, Lynx, etc) recording has been turned on before starting the Sprint Review introductions and is turned off before any non-Review-related discussion occurs. | + | * Make sure the virtual collaboration tool (Zoom, Teams, WebEx, etc) recording has been turned on before starting the Iteration Demo / Sprint Review introductions and is turned off before any non-Review-related discussion occurs. |
- | * If showing the Sprint Burn-down and other metrics takes more than ~5 minutes with any discussion expected, ask to return to this subject after demonstrations have been completed. Focus on getting feedback from the demonstrations. | + | * If showing the Iteration (Sprint) Burn-down and other metrics takes more than ~5 minutes with any discussion expected, ask to return to this subject after demonstrations have been completed. Focus on getting feedback from the demonstrations. |
- | * If the team wants feedback from stakeholders on work not yet completed, make sure there is clear separation between this and demonstrations/ | + | * If the team wants feedback from stakeholders on work not yet completed, make sure there is clear separation between this and demonstrations / discussion of completed work so there is no confusion on the part of stakeholders regarding the difference. |
====== Product Owner Options ====== | ====== Product Owner Options ====== | ||
- | As a result of the Sprint Review, the Product Owner has a number of options: | + | As a result of the Iteration Demo (Sprint Review), the Product Owner has a number of options: |
- | * Update the Product Backlog, for example: | + | * Update the Team (Product) Backlog, for example: |
- | * Restore and prioritize unfinished functionality to the top of the Product Backlog | + | * Restore and prioritize unfinished functionality to the top of the Team (Product) Backlog |
- | * Reprioritize the Product Backlog based on feedback | + | * Reprioritize the Team (Product) Backlog based on feedback |
* Remove or lower priority of items no longer needed | * Remove or lower priority of items no longer needed | ||
- | * Ask for a “Release” to implement the demonstrated functionality, | + | * Ask for a “Release” to implement the demonstrated functionality, |
* Stop the project | * Stop the project | ||
* Request additional resources if necessary | * Request additional resources if necessary | ||
- | ====== Challenges of a Sprint Review ====== | + | ====== Challenges of a Iteration Demo (Sprint Review) ====== |
- | Watch for these issues as you do Sprint Reviews: | + | Watch for these issues as you do Iteration Demo (Sprint Reviews): |
* Team demonstrates work that is not “Done” | * Team demonstrates work that is not “Done” | ||
Line 114: | Line 111: | ||
* Team does not demonstrate the product from a user / value perspective | * Team does not demonstrate the product from a user / value perspective | ||
* Team does not accept feedback well; gets defensive | * Team does not accept feedback well; gets defensive | ||
- | * Product Owner is surprised at Sprint Review | + | * Product Owner is surprised at Iteration Demo (Sprint Review) |
- | * Stakeholders not available for Sprint Review | + | * Stakeholders not available for Iteration Demo (Sprint Review) |
* Team uses PowerPoint to demonstrate software functions | * Team uses PowerPoint to demonstrate software functions | ||
* Team does not show product quality metrics | * Team does not show product quality metrics | ||
- | * Feedback is not going into Product Backlog for consideration | + | * Feedback is not going into Team (Product) Backlog for consideration |
- | * Great review, but nobody knows where the project is | + | * Great review, but nobody knows where the product or project |
+ | * Pro-forma review, where we just go through the steps and do not learn how to get better | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
+ | |||
+ | * [[https:// | ||
+ | * [[how_can_we_improve_the_quality_of_feedback_at_an_iteration_demo|How Can We Improve The Quality of Feedback at a Sprint Review?]] | ||
+ | * [[how_do_we_demonstrate_something_that_results_in_a_new_api|How do we Demonstrate Something that Results in a New API?]] | ||
+ | {{tag> |
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_we_run_our_first_iteration_demo_or_sprint_review.1447793679.txt.gz · Last modified: 2020/06/02 14:23 (external edit)