You need to enable JavaScript in order to use the AI chatbot tool powered by ChatBot

What are the common mistakes you see in sprint reviews?

What are the common mistakes you see in sprint reviews?

The sprint review is a great opportunity for the scrum team to come together with customers and product stakeholders to review what has been built, what impediments remain, and where the team are going to go next.

Some teams are great at this and improve with each event whilst others mistake the event for a presentation and fail to get the most out of the sprint review. Here are some of the more common mistakes I see when it comes to sprint reviews

Mistake 1: It isn’t a review

The purpose of the sprint review is to examine the product you are building and to decide what is working, what needs work, and to ascertain whether the product being built delights customers.

  • Are we solving the right problems?
  • Are we solving the most valuable problems?
  • Are we working on the most valuable items for customers?
  • Is the thing that we are building creating value for end users and customers?
  • Are we considering the bigger picture elements?

And you can’t do that by simply showing stuff. You must have a conversation.

So, in my experience, this is what I most commonly observe. The team create a presentation and demonstrate what they have done in the sprint but don’t set the event up to be a review that facilitates conversation and invites feedback.

How do you improve the product if you don’t have the conversations that empower the team to understand whether they are creating value and solving compelling problems?

Mistake 2: Failing to be transparent and open about what is being achieved

The sprint review offers customers, product stakeholders and leadership teams an opportunity to understand what impediments are preventing the team from achieving sprint goals. If they don’t know what prevented the team from achieving their goals, they can’t help.

Many teams avoid speaking about what they aimed to achieve in the sprint and being transparent about the impediments that prevented them from achieving their goals. It isn’t about complaining or whining, it is about being open and transparent about the elements that trip the team up.

It is showing respect to your product stakeholders, sponsors, and customers by empowering them to understand what stands in the way of progress and how they can contribute to solving that problem.

If the team are consistently achieving the sprint goal but fail to deliver on some of the items, that is a success, and the team should own that and celebrate that. If the team are failing to reach the sprint goal, it is super important that they articulate the reasons for this.

Failing to showcase the problems being encountered during the sprint means that the team are likely to keep coming up against those impediments and it prevents you from finding solutions that remove impediments, frustration and allow the team to improve.

Mistake 3: Failing to celebrate success

In complex environments, we are often building products and features that have never been built before and we are often solving problems that have never been solved before.

It is a big deal.

Getting it right, consistently, is incredibly hard and worth celebrating when you do achieve sprint goals and outcomes.

Building a working product within a few weeks is something that is worthy of celebrating.

Your customers should be delighted with this progress, and you should take the time to acknowledge the win, congratulate and thank the team for their contribution, and make it known to product stakeholders and customers that something awesome has been achieved.

We set out to do this, we overcame these problems and obstacles, and now you have something that makes your life better and easier.

A team that is appreciated is a team that consistently strives for excellence.

Don’t forget to celebrate the wins in your sprint review and acknowledge the team’s success.

Thank the product owner, thank the developers, thank the scrum master, and encourage the product stakeholders and customers to do the same.

Mistake 4: The team don’t look to the future in the sprint review

The team need to have the conversation with the product stakeholders and customers about where they are going next.

The sprint review is a great opportunity for the team to articulate what they perceive to be most important and what they anticipate achieving in the upcoming sprint and sprints.

In complex environments, things often change. A new competitor disrupts the market, or a user need becomes apparent, and so we need to inspect and adapt based on real-time feedback.

The team may think that X items are most important when in reality, circumstances have changed, and those items are no longer a priority when compared to the emerging need.

If you take time out to discuss these elements and receive feedback from stakeholders and customers, you can pivot if necessary and focus on the most important work.

  • This is what we are aiming for in the next sprint, is this still the most valuable work?
  • This is what we aim to achieve in the next 12 weeks, is that still a priority?
  • Based on what we have achieved over the past 12 weeks, this is what we anticipate delivering over the coming 12 weeks. Does that still work for you?
  • Are there any changes in the market that require us to shift our focus?
  • Is there anything that has changed over the past few weeks that requires us to re-evaluate our backlog and prioritize based on the changing environment?

Your product stakeholders and customers are the experts in their field and will know which items can be relegated in favour of shifting priorities. Having a conversation allows you to understand whether the team are focused on the right work, at the right time, and whether they need to go back to the drawing board on specific backlog items.

Take the opportunity to inform the product stakeholders and customers of where you are going next and gain agreement that this is still the most valuable course of action for the team.

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

author avatar
John McFadyen Managing Partner
John McFadyen is an Executive and Enterprise Agile Coach with proven experience working on some of the UK and Europe’s largest, most complex Agile Transformations. As a Certified Scrum Trainer, John brings a wealth of experience as an Agile coach, Agile practitioner and software developer into each of the four core courses he provides. The war stories, the insights into successful Agile transformations and everything he has learned from coaching high-performance Agile teams combine to provide course delegates with a unique, compelling training experience that transforms as much as it empowers.

Like this post? Share with friends & colleagues using the share buttons below.


Related Blog Posts

Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen