Sprint Reviews are held on the last day of every sprint. 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. 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) 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. 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. scrum team 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. Sprint retrospective 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. About Me 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! In my spare time, I write my own Blog at Just Another Tech Lead and create Free Online Calculators at CalculatorLord.com Just Another Tech Lead CalculatorLord.com

effect

Every

Iterative

Keep

Vibe Coding: AI's Impact on Software Engineering

The Most Effective Way to Run a Sprint Retrospective

Read My Stories

CalculatorLord

Too Long; Didn't Read

The Best Sprint Review Schedule for Agile Success

The Best Sprint Review Schedule for Agile Success

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

ACE Your Software Engineering Interview With a Few Tips

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

ACE Your Software Engineering Interview With a Few Tips

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps