Sprint Reviews Guidelines

This document outlines a basic structure and best practices for running sprint review meetings and applies to people of all job roles.

This is a guide only and these meetings will be tailored based on the project. For example, some projects might involve a sprint demo, following by some stats reporting, followed be a sprint planning session. In other cases, sprint planning will be run separately from sprint demos/reviews. It is up to the Scrum Master (Audacia Project Manager) to decide which approach is most appropriate considering the audience for the meeting.

The Scrum Master (Audacia PM) is responsible for:

1. Scheduling the meetings (these will usually fall on the final day of each sprint).
2. Chairing the meeting.
3. Organising demos in advance of the meeting.
4. Collating velocity and project status statistics, and ensuring the team have submitted timesheets in advance such that velocity can be calculated.
5. Recording notes during the meeting, and storing notes in a location that is accessible for the whole delivery team, including the client.
   1. Actions should be clearly visible in the meeting notes. If recording actions in markdown notes these should be consistently prefixed e.g. ACTION: JW - Do thing (where JW are the initials of the action owner).
   2. The meeting notes are not the correct location for monitoring the progress against actions. All actions should be recorded elsewhere following the meeting - either in the project tracker, or PBIs should be raised where applicable.

1. The Audacia delivery team will attend i.e. the Audacia PM (Scrum Master), developers and test engineers.
2. Audacia project oversight resources (e.g. the technical reviewer or test reviewer) will not attend, unless by exception.
3. The client Product Owner, SMEs and user acceptance tester(s) will attend.
4. Client stakeholders may attend if they choose and should be given the option, but often the meeting will be structured such that these people can see the product demo, then drop off after this point.

1. Sprint demo
2. Sprint retrospective
3. Sprint and project status
4. Sprint planning
5. Release planning
6. Any other business

Sprint demo

Please see here for guidance on planning and running effective sprint demos.

Sprint retrospective

Please see here for guidance on running sprint retrospectives.

Sprint and project status

This section of the notes is absolutely critical. It is an opportunity to record, in writing, our view of sprint and project status.

It is very important that we’re able to look back and evidence that we’ve shared this status with the client on a regular basis such that we can show we’ve effectively managed expectations and avoided any surprises.

Sprint status

Statistics presented in this section include:

1. A report on velocity achieved this sprint. This is calculated as follows: $$ effortPointsDone \over developerDaysWorked $$
2. The 5 sprint average velocity.
   1. Since the sprint velocity regularly fluctuates when large items are carried from one sprint to the next, the 5 sprint average velocity is often a more reliable indicator of performance and trends.
   2. This is not calculated by summing the velocity in each of the previous 5 sprints and dividing by 5. It is calculated using: $$ effortPointsDoneInLast5Sprints \over developerDaysWorkedInLast5Sprints $$
   3. The work items considered Done will depend on the project’s Definition of Done. Generally this will be items in the Done column, but in some cases it might be “any item in UAT Accepted or beyond”.
3. While the Done velocity should always be presented, the PM may optionally choose to present the Code Complete (i.e. “initial round of development done, but not yet tested”), QA Complete or UAT Complete velocity too, in order to provide additional insights.

General notes in this section should:

1. Explain the story behind what we have achieved / haven’t achieved this sprint e.g.
   1. “Velocity was down on the previous sprint because factor Y blocked us from delivering work item X”
   2. “Velocity increased this sprint since item #1234 was completed faster than planned”
2. Confirm whether we have achieved the sprint goal.

Project status

Statistics presented in this section include:

1. Budget usage to date, total budget, and the proportion used i.e. $$ resourceDaysBooked \over resourceDaysScheduled $$
2. Effort points completed to date, the total target effort points, and the proportion done.
   1. Note the “total” effort points should be the original target effort points based on the Statement of Work.
      1. This is not the total size of the backlog, because the backlog may have grown since the project started, and our target is still the original target not the inflated scope.
      2. This is not the total number of “must” do points. We measure ourselves against our aspirational target, rather than the bare minimum delivery.
   2. Calculated using: $$ effortPointsDone \over effortPoints $$
3. Anticipated number of effort points that will be completed by the end of the project. Calculated using: $$ effortPointsAlreadyDone + (fiveSprintAverageVelocity * developerDaysRemainingInSchedule) $$
4. The current size of the backlog, in effort points.

General notes in this section should:

1. Summarise status in words e.g.
   1. “We are 70% through the budget, and we have completed 68% of the target effort points, so we are roughly on track and believe we can catch up by the end of the project. However, the total backlog has grown since the project started, so if we are targeting completion of all items we will need to explore increasing the budget.”
2. Highlight any key risks, issues, actions or blockers.

Sprint planning

Sprint planning will usually be done outside of the main sprint review meeting. This will generally involve the Scrum Master (Audacia PM) having a meeting with the client Product Owner a working day or two before the sprint review meeting, and lining up items that are priorities for the new sprint.

The purpose of the Sprint planning section of the sprint review meeting is therefore to:

1. State the available capacity, based on the number of resource days available in the sprint.
2. Mark the planned work items as Committed, such that the whole team understand what we’re trying to achieve in the next sprint.
   1. This number should align with the available capacity. Often, some filler items will be added to the sprint and marked as Stretch items, to help ensure we have options available for signed-off work, just in case other items are blocked.
3. Agree a sprint goal.

Release planning

This is an opportunity to discuss:

1. When the next releases will be deployed to the QA and UAT environments, such that testers can anticipate when they’ll have new items to review.
2. Plans for the next deployment to the Production environment. This may involve re-capping on the target date and when the go/no-go call is scheduled for, and is a good opportunity to ensure that everyone is aware of the release plans and associated comms plans.

This section of the meeting is used to re-cap on release plans, or briefly share a provisional plan. It is used to ensure people are aware and aligned - it is not intended as a chance to go into detail. If this is needed, a separate call should be arranged.

Any other business

Standard agenda item at the end of the meeting to allow people to raise any miscellaneous points not covered elsewhere.