Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *


Tell us why you're considering making a switch:


Scrum Meetings - It’s all About Adding Value

19 Apr 2018

Scrum Daily Meeting

If one was to compile the Greatest Hits by The Scrum Naysayers and Critics, it would definitely feature the supposed overemphasis on meetings. Sometimes it is about the number of different meetings Scrum teams are supposed to have and other times it’s about their duration.

You will also often hear (or read) that such structured meetings are in clash with what it means to be Agile and that they are the servants of the dreaded waterfall.

In the vast majority of these cases, the criticisms either miss the point of different Scrum meetings or reveal themselves as criticisms of specific situations where the meetings are the least of the team’s problems stemming from otherwise poorly implemented Scrum.

In this article, we will be looking at the five most common types of Scrum meetings and how teams can get maximum value from them.


Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

Backlog Refinement Meeting

Sprint Planning

Sprint planning is one of the 5 events outlined in the official Scrum Guide and the first of the Scrum meetings that we will be looking at today.

As its name suggests, it happens before every Sprint and its main goal is to establish what can be delivered in the Increment which will result from the Sprint and how this will be achieved.

Sprint Planning is a collaborative undertaking with the Development Team, the Scrum Master and the Product Owner all doing their parts to ensure that the team discusses all (or at least as many as possible) the details of the upcoming Sprint and what the end result of it all will be - the Sprint Goal.


For the Sprint Planning meeting to deliver the maximum value, the entire Scrum Team needs to be engaged and collaborate. The Product Owner will suggest Product Backlog Items that he or she believes are of the highest priority at the moment and the team assesses how much can be delivered. They also work out how to approach the Backlog Items and the Product Owner clears up anything that might be unclear.

By the end of the meeting, the Development Team knows what they will be working on in the next Sprint and they should be able to explain how they intend to tackle the work at hand.

If you want to read more about how to do effective Sprint Planning, make sure to check out this article.

Daily Scrum

Daily Scrum is probably the most widely known of all Scrum meetings, or even Scrum concepts in general, in that it has been adopted by teams which do not necessarily work in the Scrum framework.

Ironically, the Daily Scrum meeting is also the meeting that is most often done wrong. For example, it is not that uncommon for Daily Scrum meeting to turn into an exercise in micromanagement where the Scrum Master (usually one that doesn’t understand the point of his or her role) expects to get reports from the Development Team on what they have been doing.

The Daily Scrum meeting is not about this. It is a 15-minute event during which the team communicates about what they have been doing and what they plan to do, identifying obstacles and finding ways to help each other and boost the synergistic approach to working on Sprint Backlog Items.

Daily Scrum meetings will vary from one team to another and from one organization to another, but they should always deliver value by promoting inspection and adaptation. In addition to this, Daily Scrums actually reduce the need for additional meetings and aid in knowledge sharing.

Read more about Daily Scrum meetings here.

Sprint Review

A Sprint Review is a meeting which is held following the end of a Sprint and its main goal is for the Scrum Team and additional stakeholders to communicate and collaborate on the work that has been done.

In addition to this, the Development Team also shares any problems that they encountered and how they overcame them and they also answer any questions about the work that was done during the Sprint and which they demonstrate during the Review.

It has to be stressed that the Sprint Review is not a status meeting where the Development team gives a structured report on what they had done, but an informal meeting that adds value by getting feedback from the stakeholders and fostering collaboration between all parties involved.

At the Sprint Review, stakeholders other than the Scrum Team are encouraged to share their opinions and findings that might impact the product moving forward. This will help the Scrum Team decide how to adapt to the potential changes in the marketplace and prioritize future increments more efficiently. The Product Owner will also discuss the Product Backlog as affected by the work done during the Sprint.

By the end of the Sprint Review, the Scrum Team should have a revised Product Backlog which will then be used to plan future Sprints. In other words, an efficient, successful Sprint Review meeting can be of huge help come the next Sprint Planning.


Sprint Retrospective

The Sprint Retrospective is the final of the four meeting events prescribed by the Scrum Guide and it adds value by making the Scrum Team better. At the Sprint Retrospective, the Team looks inwards and inspects itself, trying to identify ways in which it can become a better functioning unit.

This meeting takes place between the Sprint Review and the next Sprint Planning and it should always be a positive event where the Team inspects their latest Sprint in terms of relationships between team members, the process itself and any tools, like Scrum software, that the Team might have used. During the Retrospective, the Team identifies the major impediments and discusses the ways to remove them so as that future Sprints are more enjoyable and productive.

In the ideal Scrum, the improvements identified during the Sprint Retrospective should be discussed and implemented organically, but the Retrospective still provides a formal opportunity to do so. This is especially useful for “young” Scrum teams which have still not reached that point where they improve their Scrum process on an ongoing basis.

Backlog Refinement Meeting

We wrote about the biggest Product Backlog mistakes a few weeks ago and we mentioned that Product Backlog refinement is an integral part of any Scrum implementation. And while some Scrum Teams collaborate on this task on an ongoing basis, for many of them, a formal, structured Backlog refinement meeting is the best course of action.

This kind of a meeting is not mentioned in the Scrum Guide, but its potential to add value to the Team, their process and the product(s) they are working on is not to be scoffed at.

A formal Backlog refinement meeting is the perfect opportunity to discuss Product Backlog Items, take a closer look at those that are planned for upcoming Sprints, rethink the existing prioritization of PBIs and perhaps do a bit of a clean-up.


Once again, it is supposed to be a collaborative effort where the Product Owner will consult the Development Team and listen to their opinions and advice which stem from the work they had done on the PBIs in the past. This meeting will also provide the Development Team with another opportunity to learn about the upcoming PBI priorities and ask questions that will help them down the line.

This type of meeting will add value in a number of ways - from helping to keep the Product Backlog lean and well-prioritized to providing the Development Team with additional insights into future Sprints and the product as a whole.

Closing Word

Scrum meetings are all about adding value and making the software development process better. They help Scrum Teams grow together; they help them deliver better products and they help them deliver business value to the customer. Counterintuitively, through their structured nature, they also help minimize the need for additional excessive meetings.


Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.