Skip to content

How does an Agile coach approach sprint review planning?

How does an Agile coach approach sprint review planning?

Does the Agile coach need to be there? I would start by asking what the team are trying to achieve by having an agile coach present for the sprint review and to understand how the agile coach can deliver value, in conjunction with the scrum master, for that unique application and environment.

So, it depends on what they are there to do:

  • Are they filling in for the scrum master?
  • Are they leading a particularly difficult sprint review for a specific reason and outcome?
  • Are they there to teach the scrum master and team how to conduct a great review?
  • Are they there to observe the scrum master and provide feedback and recommendations?

Make sure the team are prepared

Regardless of the role that you are there to play as an agile coach, you want to make sure that the scrum team are well prepared for the sprint review.

It isn’t a demonstration, and it isn’t a presentation.

The sprint review is a great opportunity for the developers, product owner, product stakeholders and product sponsors to all come together and understand,

  • what has been achieved in the sprint,
  • what the team aimed to achieve,
  • why there is a gap between the target and outcome,
  • what impediments prevented the team from achieving their goal,
  • what worked,
  • what has been delivered or built,
  • where the team are going next,
  • how stakeholders, customers and sponsors can contribute to future success.

 You want to make sure that the team understand the structure of a sprint review and that they have everything ready for the sprint review.

Agenda for a sprint review

Let’s walk through the agenda for a sprint review.


We start by talking about the goal of the sprint. We talk to our product stakeholders and product sponsors about what we aimed to achieve in the sprint.

A product owner is a great person to kick this off because they are the ones who would have prioritised the backlog and provided the team with insight into what needed doing, why that is important, and how the new feature or product will serve customers and end users.

That said, a developer could do a great job of this too. Just make sure they are prepared.

The person leading this opening phase will speak about what the team aimed to achieve, what the sprint goal was, and what items were brought into the sprint backlog to be delivered.


You would then speak to what happened. Speak to what the team actually achieved during the sprint.

  • This is what we built.
  • These are the items on the backlog that were delivered.
  • These are the items that we couldn’t deliver.
  • This is the sprint goal that was achieved.


Product stakeholders, sponsors and customers are genuinely interested in the product that is being built. Hopefully, they are also interested in understanding how they can help to make the product a success.

When you address the impediments to progress and speak openly and honestly about the things that prevented the team from achieving a goal or completing an item, you are offering others the opportunity to offer advice, insight, or commitments to help the team move forward.

If it’s an internal policy that disrupted the flow of work, a senior leader within the organisation can take action that removes that impediment for the team and allows them to complete the item or feature in the next sprint.

If a product stakeholder understands that a lack of customer feedback at a crucial moment in development caused a delay, they can commit to creating a focus group of customers to ensure that the developers have the necessary feedback loop within the next sprint cycle.

There is a myriad of ways that others can help us achieve our goals, and discussing the things that prevent us from achieving our goals helps them to understand what blocks progress and how they can contribute to future success.

Remember, when we are talking about this, we are not whinging and making excuses, we are clearly communicating the barriers to progress and how they impact our performance. We are helping others to understand what we need to progress and inviting them to contribute.


At this point, we invite the stakeholders and customers to review what has been delivered.

Rather than a show and tell, the most confident teams invite the sponsors, stakeholders and customers to interact with the new feature and experience it for themselves.

You want people to actively engage with what has been created and receive their honest feedback on whether it solves their problem or helps them achieve their goals.

With software, this is relatively straightforward. In something like web development, you would actively invite people to browse the website and interact with the new features to ascertain whether value has been created through the sprint.

This should be fun, interactive, and engaging.

Observe people as they interact with the product or feature and actively ask questions afterward to understand their experience, the utility of what has been created, and whether it delights product stakeholders and customers.

If your product isn’t at the level where the stakeholders and customers can play with it just yet, let the team lead this demonstration by walking people through the system and how the new feature adds value to the end-user or customer.

Again, make sure it is interactive, engaging and fun.

The purpose of this demonstration is to invite conversation about the product, the new feature and what still needs to be achieved before the product is considered valuable.

You want people’s honest opinion and feedback so be ready to accept the good with the bad as equally valuable. This is a learning moment for the team. It gives them the opportunity to understand, first hand, whether the sprint has been successful or not and why.

As the agile coach or scrum master, you are going to be actively facilitating these conversations. You are going to help the team connect with the product stakeholders, sponsors and customers in a way that yields valuable and actionable insights.

Asking questions like:

  • What do you think?
  • What do you like?
  • What don’t you like?
  • How can we improve this?
  • Does this meet your expectations?
  • What would you like to see?

Really delving deep into the new product or feature and allowing people to respond openly and honestly. Facilitating conversations that promote understanding. Nothing is off the table as long as it is respectfully delivered.

People may not like what has been achieved, and that’s ok. You would rather know early in the product development process that you have missed the mark and allow the team to course correct in the following sprint.

All feedback is valuable.

After the review, we can work with the product owner to get the right items in the backlog and prioritised based on the feedback we receive in the sprint review.

Talking about the future

The final phase of the sprint review is to talk about the future.

You are going to discuss where the team are going next, why that is the focus of their work, and how that will deliver value to customers and stakeholders.

You really want to lean on your product owner for this phase of the sprint review.

This is where the product owner demonstrates their understanding of both the product and the customer. This is where they demonstrate their knowledge of what truly matters to end users and how the team aim to delight customers moving forward.

Some product owners may use a sprint burnup chart to demonstrate how much has been achieved over the past few months, and based on that consistent delivery rate, estimate what could be delivered in the next sprint and the sprints that follow.

This phase provides product stakeholders, sponsors and customers with insights into what they can anticipate next and invites a conversation about whether that is valuable to them or not.

This is a phase that allows customers and stakeholders to affirm that we are on the right track or provide us with feedback and insight as to why we need to pivot in a new direction.

All of this feedback informs both the product owner as well as the developers whether their efforts are focused in the most valuable areas or not.

If you tee your sprint review up in alignment with this agenda, I am confident that you will extract the maximum value from this scrum event and ensure the team are focused on the most valuable work moving forward.

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster