12 Antipatterns Ruining Your Sprint Reviews

‍Alignment is everything. And sprint reviews are where alignment happens most. It’s arguably one of the most important ceremonies we run.

But it’s really easy to screw up sprint reviews. Maybe we’re making them murky and imprecise, uninclusive, unengaging, or a downright waste of time.

So it’s worthwhile having a look at these 12 common sprint review antipatterns. 

I’ve divided them into four categories of antipattern – communication, engagement, goal and expectation.

If you spot some of these in your own reviews, you’re not alone – almost every engineering or product leader, owner and manager I speak to struggles to eliminate every antipattern.

What bad sprint review habits do you spot in your own team? What other antipatterns would you add to this list?

I hope by the end, we’ll all be a touch better at spotting these antipatterns and have a better understanding of how to run sprint reviews. Let’s get into it.

Four communication antipatterns

1. Feedback delay. Instead of embracing continuous feedback and dialogue throughout sprints in line with the spirit of Agile, developers withhold feedback.

Feedback shouldn’t be confined to specific ceremonies and meetings – Scrum Masters and leaders need to promote continuous dialogue.

2. Inegalitarianism. Scrum is egalitarian by nature. But sometimes, some voices are heard more than others. For example, the Product Owner might present “their” accomplishments.

Scrum emphasises collective responsibility, and development teams succeed or fail together. Teamwork needs to be valued over individual credits.

3. Resistance to feedback. Rejecting feedback is somewhat innate in human nature.

But Product Owners, Scrum Masters and teams need to be open to feedback, and Scrum Masters and leaders need to nurture environments where feedback is thought of as a vehicle to progress rather than an affront.

4. Overcommunication. It’s tempting, and easy, to include details which aren’t immediately relevant or could have been addressed through a simple message or digest.

Use concise but context-rich sprint reports to kick off your meeting with everybody on the same page about the key takeaways. This also helps everyone discern what’s important and stay focussed on what matters.

‍

PS – here’s some more reading about 3 simple reporting mistakes dev teams often make.

Overcoming communication antipatterns with transparency

When we make transparency safe, we can be so much more productive and avoid these communication sprint review anti-patterns.

This starts with embracing Agile principles and running consistent, best-practice Scrum ceremonies throughout the software development lifecycle. For example, you need your regular daily stand-up to maintain a constant flow of information, and regular sprint retrospectives for continuous improvements.

During sprint reviews, it’s crucial everybody understands that these sessions are two way dialogues. They’re only effective when there are functional feedback loops. Make sure your team clarify the context and takeaways when they communicate. That way, everyone understands the significance.

Use a sprint report to get everyone on the same page and aligned on what matters during sprint reviews.

They should be concise, but full of context and the right amount of commentary.

If you use Jira or Linear, you can use a tool like Stepsize AI to automatically report on sprints without liftiig a finger.

Stepsize AI is a security-first tool that automatically observes everything that happens in your issue tracker, and forms connections between your tasks, projects and goals.

It uses this to generate a report with just the right amount of context and detail.

Learn about Stepsize AI – you can also get your team’s first sprint report for free.

Three engagement antipatterns

1. Passive attendance. Although key stakeholders attend, they might do so in relative silence. They don’t contribute feedback or ideas.

We need to design our sprint reviews in a way that actively involves each stakeholder. Try formats such as hands-on product testing and interactive Q&A sessions.

2. Chronic underattendance. Sometimes, only specific team members will consistently come to the sprint review.

Every Scrum team member should be present as often as possible. It means they can contribute their insights, and keep aligned with feedback and goals. If attendance is an issue, it could be discussed at the sprint retrospective.

3. Presentations over demos. It can be tempting for teams to rely too heavily on presentations.

Opt for interactive showcases, wherever you can. We need to let stakeholders drive discovery, and we can do this by making “show, don’t tell” the mantra.

Overcoming engagement antipatterns with inclusivity

Sprint reviews are effective when everybody feels able – and excited – to contribute.

The worst thing we can end up with is a monotonous, one-way delivery that is the same, week-in, week-out.

We have to find ways to engage every stakeholder in our discussions or activities. We have to encourage everybody to speak, and we also need to make it feel safe to do so. Sprint reviews don’t need to be overly formal affairs. Pass around the keyboard and get everyone involved.

We can open dialogue by soliciting feedback. Of course, we have to also take that feedback seriously. Always make a note of feedback and ensure there are practices for assessing and resolving it, and channels to discuss it.

Two goal antipatterns

1. Side gigs. Developers get focussed on things that aren’t aligned with the sprint goals.

When we deviate from what’s agreed during Sprint Planning, we have to do so collaboratively, and with the goals set for the sprint in our minds. Where engineers uncover “side projects” – perhaps because of finding technical debt or thinking of a new feature that would be cool – it can throw sprints off course. Tech debt should be logged and discussed together, while ideas can be shared with stakeholders during this meeting or Sprint Planning.

2. “Done” – ish. Developers routinely show work that isn’t really “done”.

Sometimes, of course, there’ll be a good reason to show unfinished work, where it can provide insight. But the concept of “Done” is a central principle of Scrum – successful Scrum teams don’t need to make a habit of showing unfinished work. Instead, focus on work that is “done”.

Overcoming goal antipatterns with clarity

Things start to fall apart quickly when Scrum teams have a fuzzy idea of sprint, product and project goals.

We need to continuously align and re-align goals with stakeholders, and we also need to lead people to focus on their goals and think critically about tasks which don’t align or would disturb progress towards them.

And of course, the goals themselves need clarity. Mike Cohn – a leading Agile and Scrum expert – suggests breaking down goals into measurable milestones that make it possible to show tangible progress. If a goal isn’t engaging stakeholders, maybe it’s time to reassess how relevant or feasible it is.

Even doing simple things like reporting on project and sub-project completion metrics will help with this.

You can use Stepsize AI’s automatic sprint reports to show completion metrics at a glance during your sprint reviews.

Three expectation antipatterns

Aligning the team's and stakeholders' expectations is vital.

1. Review as an approval process. Sometimes, stakeholders treat the review as a sign-off process.

Everyone needs to understand that approval isn’t the purpose of reviews. That isn’t to say approvals cannot happen in reviews, but the focus needs to be on gauging progress, adapting to new information, changing goals and feedback and getting aligned on what needs to happen next.

2. Fixation on granular detail. Stakeholders outside the Scrum team will want to walk away with an overarching understanding of product progress against goals. 

Scrum teams need to tell a compelling story about the sprint that explains how progress has worked towards the goals that were agreed upon at the last sprint review. Avoid fixating on details.

3. Assuming knowledge. Scrum teams are prone to assuming too much knowledge around technical details, user stories or the significance of certain deliverables, when sharing with stakeholders.

This throws people into misalignment. Recap the context before kicking off and clarify unfamiliar terms. Spending a few moments doing this ensures everyone’s on the same page.

Overcoming expectation antipatterns with understanding

It seems obvious, but everybody needs to understand the purpose of a sprint review.

We’re trying to create alignment. Start every sprint review by reviewing a concise, context-rich sprint report, such as an automated review from your Jira or Linear data by Stepsize AI. Then, there will be an interactive show-and-tell, followed by open dialogue to bridge the gap between technical implementation and commercial vision. Finally, the sprint backlog is updated.

To ensure there’s always a shared understanding, set expectations and explain the context before diving into anything technical. Although you have a regular sprint review, we also need to maintain open channels of communication.