Secret ingredients to quality software


Do you create a Sprint Review/Retro email?

Last updated by Christian Morford-Waite [SSW] on 26 Feb 2021 01:16 am (2 months ago) See History

After any Sprint Review and Retrospective, an email should be sent to all the stakeholders to update them on the outcome from the sprint:

  • Subject: <Client Name> Sprint XX Review/Retro
  • This is a reply to the Sprint Forecast email
  • Screenshot of Burndown from Azure DevOps
  • Breakdown of work completed (including current code coverage value)
  • Link to test environment
  • Relevant notes from the retrospective
  • CC -

Hi [Product Owner],

Sprint in Review: [Sprint Number]
Sprint Goal: [Goal]
Sprint Duration: [Number of weeks]
Project: [Project Name]
Project Portal: [Link to project Portal]
Test Environment: [Link to test environment]
Product Owner: [Product Owner Name]

Attendees: (Optional as they may be in the to and CC)

Sprint Review

| ID | Title | State | Effort | | --- | --- | --- | --- | | 24124 | UI Improvements | Done | 4 | | 24112 | Integrate Business Logic to MVC app
| Done | 8 | | 24097 | Styling | Committed
| 16 |

Figure: Sprint Backlog from [Link to Sprint Backlog in Azure DevOps]

As per, we review:

  1. Sprint Burndown (a quick overview of the sprint)

Figure: Sprint Burndown

  1. Code Coverage (hopefully tests are increasing each sprint) XXX
  2. Velocity (Optional) XXX
  3. Burnup (for the release - the whole project, how are we tracking for the big picture?)

Release Burnup
Figure: Release Burnup

  1. Production Deployments (How many times did we deploy to Production?)

production deploy
Figure: Deployments from Octopus Deploy

  1. Application Health Overview Timeline (For the entire Sprint)

Application Insights
Application Health Overview Timeline.png


**Did we do any experimental work? **

<insert details of any trial/error processes, and ensure all detail is captured as per>;

<insert details of any problems for which no solutions existed, and ensure detail is captured as per>;

Sprint Retrospective

As part of our commitment to inspect and adapt as a team we conduct a Sprint Retrospective at the end of every Sprint. Here are the results of our Sprint Retrospective:

What went well? <insert what went well from retro>

What didn’t go so well? <insert what did not went well from retro>

What improvements will be made for the next Sprint? <insert what improvements will be made for the next Sprint>

Definition of Ready - Optional

<insert the definition of Ready. Normally that the PBIs are Sized with Acceptance criteria added>

Definition of Done - Optional

<insert Definition of Done. Normally that it compiles, meets the acceptance criteria, and a test please has been sent if relevant>

<This is as per the rule: />

Figure: Good Example - Template for Sprint Review/Retro Email. Subject: Sprint xxx Review/Retro

Ulysses MaclarenUlysses Maclaren
Drew RobsonDrew Robson
Chris BriggsChris Briggs

We open source. This page is on GitHub