Sprint Reviews are held on the last day of every sprint.
Different teams may have different length sprints, but in general, a Sprint is either two or three weeks.
Therefore, sprint review meetings are held every two or three weeks (always on the last day of the sprint)
Let’s dig into more about what a sprint review meeting is, and what it’s used for.
What is a Sprint Review?
Definition and purpose of a sprint review
A Sprint review meeting is a meeting that is attended by the entire scrum team as well as key stakeholders for the project.
A successful sprint review will be focused on the work that has been completed towards the product, in the previous sprint.
During the sprint review, the agile team (mostly the development team) get key feedback from the stakeholders about whether or not they are on track with what they are working on. Did they deliver what was required and are they on time.
Importance of sprint reviews in Agile development
The sprint review is one of the key agile events in Scrum.
One of the core agile principles is iteration and improvement.
The sprint review allows for small and quick iterations of improvement (product increment) whilst continually improving the product (through feedback).
The Purpose and Benefits of Sprint Reviews
Iterative feedback loop
Agile relies on iteration to succeed.
Agile sprint reviews give regular feedback from stakeholders every two weeks (or whatever sprint review frequency your team has). This is very quick compared with other project planning techniques such as Waterfall.
People are familiar with compounding in finance, but I think that compounding in processes is less talked about. With each review that occurs, the process gets better. You then build upon that better base by getting better at the next review and so on.
The quick sprint review frequency affords you rapid adjustment based on feedback from product owners and other key stakeholders.
Early detection of issues
Agile likes to fail fast.
If you’re going to write software that deviates from what your Product and customer want, make sure that someone spots it early and course corrects.
It’s far better to waste two weeks (or however often your sprint reviews conducted) than 6 months (typical for Waterfall process)
Opportunity for iterative refinement
Having your sprint ceremonies every two to four weeks allows you to become better at planning the further through the project you go.
Whereas in Waterfall you may spend months planning the entire project and then set off writing code following the plan exactly (regardless of if it seems wrong), in agile teams, you plan as you go, so the further into the project you go, the better you know the product and code, and the more accurate your planning is.
Adaptation to changing priorities
Anyone who has worked in Software Engineering for long enough (or business in general) will know too well that what is important today is forgotten tomorrow.
The Development Team will be told by the Product owner to lay down tools and focus on new client X who is the saviour of the company.
Next week, client Y enters the picture and client X is relegated to the lower leagues of priority.
I’ve seen it time and time again.
Fortunately, Agile has you covered here.
Because you are working in a method that allows for a change of direction every two weeks, you are no more than two weeks away from being able to course correct or have a new priority enter.
Now, let me be clear, I do not approve of throwing away an entire project part way through and having a new top priority enter every couple of months, I’m just saying that I think Agile teams generally deal with this quite well.
Empowerment of stakeholders
Sprint reviews give stakeholders a peek into the otherwise blackbox nature of the software development lifecycle.
Every two-week sprint, stakeholders get the chance to see what has been worked upon as the team members demonstrate their hard work.
Stakeholders then get to give feedback, get status updates and generally be much more involved in the project than they may be without regular sprint updates.
Sprint Review Frequency and Timing
End-of-sprint timing
The Sprint review is held at the end of each sprint. This would generally be every two to four weeks.
The length of sprint is designed to be long enough to deliver significant and valuable work, but short enough so that you can quickly and iteratively deliver to the customer.
Common sprint durations and their impact on reviews
Usually, sprint lengths are between 1-4 weeks.
From my experience, I’ve seen two and three week sprints used the most and to bests effect.
Adapting standard frequencies
Agile wouldn’t be very agile if it didn’t allow for (or even encourage) change based on feedback.
If a two week sprint doesn’t work for you, try a three week sprint. If that’s worse, move back to two week sprints.
I’ve found that different teams and different projects work better within different time frames.
Don’t be afraid to change.
Factors to Consider When Scheduling Sprint Reviews
Project complexity and size
If you are starting a very complex project from scratch, it may be infeasible to deliver anything of value in two-week increments. You may need to start off with three-week sprints if you want to demonstrate valuable output every sprint.
Conversely, complex projects may actually need more regular reviews if you are requiring stakeholder feedback to ensure alignment between the development team and Product.
Team size and distribution
If you are working in an office together and your scrum team is located next to major stakeholders, you may not need as regular stakeholder feedback as if you are all working remotely across timezones.
Whilst I’m a fan of WFH, there’s no denying that information passes quicker and more easily in person.
Stakeholder availability
If the person with the most knowledge of the product you are trying to deliver is the managing director, chances are you won’t be able to tie them down for a couple of hours every few weeks.
When I worked for start ups and small companies, the CEO/Managing Directors were so involved in the product as they typically were product experts. They also had a lot of other commitments, meaning we our scrum events (Sprint retrospective, spring planning, sprint review) had to be at a lower frequency.
Conducting Effective Sprint Review Meetings
Encourage active participation
Agile requires honest feedback.
If you have a psychologically safe environment, people will want to participate more and give their honest feedback.
Psychologically safety also helps create a truly collaborative environment.
Foster open communication
There should be no boundaries between the most junior and most senior members of the review.
Everyone should have a voice that can be heard and taken in.
If people are afraid to share, your sprint review will be less effective.
Focus on progress and improvement
Rather than simply talking about exactly what you’ve worked on, also cover how much overall progress you’ve made for the project overall.
Showcase process enhancements and other improvements to the product and project delivery.
What Happens During a Sprint Review?
Review of completed work
Review the completed work from the sprint and get stakeholder feedback as to whether the work delivers what was expected.
Take note of feedback and plan any required changes in to the next sprint.
Sprint Review Best Practices
Consistency is key: establishing a reliable rhythm
Ensuring that you have a repeated meeting booked out for the same time and the same place, every 2 weeks for the next six months gives people time to arrange other work and meeting to make sure they are able to attend the sprint review.
Prepare for success: crafting an effective agenda
Keep the agenda simple and consistent.
Work through your Jira items (or whatever other planning and tracking software you use) and have pre-recorded demos with a presenter talking through what the room is watching.
Ensure that the agenda is clear, concise, and focused on progress and improvement.
Conclusion – How often are sprint reviews conducted or held?
Well, how often are sprint reviews conducted or held?
At the end of every sprint.
How long are sprints? Between two and four weeks.
My name is Ben and I’m a Software Engineer and Software Engineering Manager.
I’ve been writing Software and leading people for 20 years!
I also write on my own Blog, Just Another Tech Lead
