Azure DevOps Guidance: Sprint Reviews

What do we do in a sprint review/demo?

First, we review with the customer and stakeholders the following:

• The goal(s) for the sprint
• Changes to the plan during the sprint
• What the team accomplished during the sprint

Duration: Not more than 10-20 minutes depending on questions coming out of the review.

Next, we transition to the demo, introducing the developers who will be showing and explaining the work accomplished. This is our chance to show the customer value from their investment. This will open up into questions and feedback from the customer and stakeholders. We want to get to this phase of the meeting quickly because this is where most of the meeting’s value is derived.

Duration: Up to 30 minutes.

Finally, we open the floor for discussion, questions, and feedback.

Duration, remainder of the meeting time.

Total meeting time: 60 minutes or less.

Scheduling the sprint review

Try to secure the time of the team, product owner, customer, and stakeholders at least two weeks prior to the meeting. Individual calendars can quickly fill up within those two weeks, so getting in on the calendar well in advance is often your best chance of securing people’s time.

Try to capture the full list of expected attendees near the beginning of the project so that you can begin marking out time in calendars well in advance.

A good practice for scheduling sprints in general is to start sprint planning on a Wednesday and close the sprint with the review on a Tuesday. The majority of observed national holidays land on Fridays and/or Mondays. Additionally, people have a tendency to leverage the timing of holidays to bookend their weekends with time off. In order to maximize meeting attendance and to not have to reschedule recurring meetings, it’s best to book meetings when they are least likely to land on one of these days.

Another good practice in sprint ceremony scheduling is to NOT make sprint reviews, planning, or retrospectives recurring meetings. The list of attendees may change from sprint to sprint as the project transitions from one phase to another, such as from data ingestion to data intelligence, data visualization, and data science work. Daily stand-ups are best schedules as recurring, but only for the individual sprint; each sprint should have its own recurring schedule and list of attendees.

Finally, if your project happens to run through the winter holidays, especially the last two weeks of December, you may find it very difficult to secure everyone’s time on the calendar or get much done, have sufficient time to prepare for a sprint review, or even have much to show for the sprint. In this case, you may want to consider extending that one sprint an extra week to allow the team to regroup after the new year and get back into their rhythm.