Scrum is a popular framework for agile software development. It is well known for its events, such as the Daily Scrum or Sprint Planning. If you’re wondering what is the most important Scrum event, this article will go into that very topic. The answer isn’t very straightforward, but the discussion is valuable. So let’s find out.
Scrum has a number of events. Five to be specific. They are:
They are all listed and defined in the Scrum Guide.
What do they all mean though? We will look at each one in turn.
The Sprint is obviously the core part of Scrum. All works takes place inside a sprint. As soon as one sprint ends, the next sprint begins. The sprint is the basic horizon for the team’s planning, work and inspection / adaptation cycle. Scrum can’t exist in any way without sprints.
So you might think the sprint is thus the most important event.
So while it technically is an event according to the Scrum guide, I more think of it as a basic container. And the Scrum events go inside this container. So I wouldn’t be happy saying it is the most important event. It is at a more basic level than that. It is the basic way time is constructed within Scrum.
Sprint planning is a very important event. It happens at the start of the sprint. It is where the team confirms a Sprint Goal, and selects Product Backlog Items for the sprint that support that goal. And a plan of how to deliver those items. This plan is created by the team, not forced upon them.
This goal, the backlog items and the plan to deliver them, make up the Sprint Backlog.
Sprint planning is therefore essential to the core idea in Scrum of planning and working in small increments. As opposed to the traditional big project plan approach. Which you would find in Waterfall methods such as Prince2.
This is probably the most well known Scrum event. It is often mistakenly named as a “daily standup” (which was a concept in Extreme Programming). The Scrum name is definitely “Daily Scrum”, however.
This is a crucial event because it enables the short Inspect and Adapt cycles. Every day, the team discusses how they are progressing towards meeting their sprint goal. They update their sprint backlog, based on their progress, and any other factors that have emerged during the sprint. They discuss how they can help each other to progress their work.
Many people think it is just a status update. Or a chance for the developers to answer the dreaded “three questions” (what I worked on yesterday, what I’m working on today, what blockers am I facing). It is more about the team inspecting their progress and coordinating their work. To maximise the value they deliver and help ensure the sprint goal is met.
The Sprint Review is a crucial event, especially for those outside the team. It is the opportunity for stakeholders to inspect the work that the team has done in the sprint that is just ending. The Sprint Review is therefore extremely important for transparency.
Transparency is one of the three basic pillars of Scrum. And while the team works in way that is transparent to themselves, people outside the team need that transparency too.
And a Sprint Review enables the crucial inspect / adapt cycle too. Stakeholders not only get to inspect the work, but also discuss with the team on what should be done next.
The Sprint Retrospective is an important event because it provides an opportunity for reflection and continuous improvement.
As you know, the Sprint Review is an opportunity for the team (and stakeholders) to inspect the product. Well, the retrospective is a chance for the team to inspect itself! So it is part of the inspect / adapt cycle too. But instead of the team improving the product, they are improving themselves.
Continuous improvement is deeply embedded into agile. In fact, it is one of the twelve principles in the agile manifesto.
This answer might seem like a bit of a cop-out, but it has to be “all of them”! Scrum is incomplete without even just one of those events. Losing all but one would give you something that barely even resembles Scrum.
If you just had to have just one, and were prepared to not call it Scrum, then I would say Sprint Review. It might sound like a strange answer. But having stakeholders regularly inspect the product and provide feedback and direction is so crucial. The team could maybe plan in an ad hoc way (instead of in a specific planning meeting).
Obviously, losing daily feedback cycles and a sprint-based continuous improvement event would be pretty severe. But if I had to pick one, it would be that.
In summary, all the Scrum events are crucial. But if I had to pick just one, it would be the sprint review.
Do you agree? It’s a hard call, and I could see it going another way. Let me know your thoughts in the comments! I will read and reply to each one.