We do Scrum but…

We hate the Scrum meetings!

A kick in the ScrumBut — episode 4

Many people hate one, some or all of the Scrum meetings. What I hear often is that they don’t add value. People see it as a waste of time because nothing comes out of it. Or worse: they kill productivity, they kill the flow of the team.

I hear these remarks a lot. I believe it is a concern that a Scrum Master has to take very seriously.

What you certainly shouldn’t say is that we have to have the meetings because the Scrum Guide says so. “It say so” is not a good enough reason. It’s vital to understand why the Scrum Guide says so. Here is a quote from the Scrum Guide that already sheds a light:

“Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” — SG

Ironically, these events exist to limit the number of meetings and to be effective.

In most cases the Scrum Guide states what the maximum length of a meeting should be for a 1 month Sprint. It is up to the Scrum Team to decide what fits them best. Maybe they can manage with shorter events. But maybe not at all, when the true meaning of the events is fully understood.

But let us tackle all of the events and discuss some concerns in detail.

The Daily Scrum

The pain

I have seen awful Daily Scrums. Those went a bit like this:

John: “Where is the rest of the team? Are they getting coffee first? Is this going to be another 30 minute stand-up?”

Ten minutes later… everyone is ready…

Daisy starts: “Yesterday I worked on item 123. Today I will continue to work on item 123. No impediments.”

Phil: “Yesterday I couldn’t work on item 456 because I had to attend all kinds of meetings. Today I will again not work on the item because of new meetings. No impediments.”

Alice: “Yesterday I couldn’t work on item 789 because of the impediment with the access rights. Hopefully I can work on that item today. My impediment is that I don’t have the access rights.”

Etcetera etcetera… and then:

Scrum Master: “OK, let’s now go through JIRA to update all the items”.

I hear another kind of concern about the Daily Scrum too. From teams that perfectly work together. They tackle things on the spot and help each other out when issues occur. Why would such a team spend the time on a Daily Scrum?

So why do we have the Daily Scrum?

As the Scrum Guide explains the Daily Scrum is the event where the Development Team plans work for the next 24 hours.

It’s the 15 minutes a day where the Development Team reflects if they are on track towards meeting the Sprint Goal. It exists to optimize the chances to meet the Sprint Goal.

“The Daily Scrum exists to inspect if the team is still on track to meet the Sprint Goal and to adapt if needed.” — SG

It also exists to increase transparency:

“Transparency: Significant aspects of the process must be visible to those responsible for the outcome.” — SG

Is everything up-to-date, are we all on the same page, are we up-to-speed?

As a result it also benefits teams that closely cooperate throughout the day. It is 15 minutes of reflection.

The zombie-3-question stand-up is an anti-pattern. Something you wish to repair asap. The Scrum Guide suggest these three questions as a way to do the Daily Scrum. Note the difference to the questions above:

  • “What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The trick is to understand that “I” means: what have I done and what can I do to meet the team goals within the Sprint?

There are multiple ways to do have a great Daily Scrum. Go explore the possibilities and experiment. See what best fits your team!

The Sprint Planning

The issue

This is the remark that I hear often in relation to the “Too many meetings” complaint:

Why would we have a lengthy session to plan our work? That is a lot of time down the drain. For the entire team. Why can’t we just pick the most important items from the Product Backlog. It will take us 15 minutes at most!

This hints to the following anti-pattern: many teams close themselves up in a meeting room, open JIRA (or another tool) and add the items based on what is highest on the backlog. The Product Owner is basically the only one providing input. After this exercise the senior members of the team are dividing the items over the team.

So why do we have the Sprint Planning?

According to the Scrum Guide the Sprint Planning exists to answers the following:

“What can be delivered in the Increment resulting from the upcoming Sprint?” — SG
“How will the work needed to deliver the Increment be achieved?” — SG

Hence it is not only about picking up the items from the Product Backlog. It is also about:

  • Assessing what the projected capacity of the team will be. What has the capacity been in the recent past? Will there be changes in the team that impact the capacity (people joining the team, leaving the team)? Will people be off?
  • What will be our Sprint Goal? What is the team’s objective for the coming Sprint?
  • The Development Team decomposes the work planned for the first days of the Sprint. The team will discuss how they are going to approach the first item(s) chosen to be picked up.

Here is an example how you could have a great Sprint Planning.

Have the Sprint Planning at the work-floor, with a whiteboard. Here the Product Owner gives a vision of where she/he hopes to be at the end of the Sprint.

Next everyone chips in to discuss a solid Sprint Goal. The Product Owner identifies a number of Product Backlog Items that will help to meet the Sprint Goal. Then the team works together to create a plan for the next few days, on the whiteboard. People are free to fly-in and out, have short break-outs in smaller groups or pairs, look stuff up and ask others for help.

Administration (suppose you use JIRA or another tool) can be done at a later stage.

The Sprint Review

The issue

I have seen teams that actually dropped the Sprint Review because they demo their finished items whenever they are ready. To repeat this in the review meeting is seen as a tedious exercise.

Other people state that they are constantly in close collaboration with the business or user and that they are in sync, making the Sprint Review obsolete.

While the mentioned practices are great as it is all about direct communication and short feedback loops, I disagree with the notion that the Sprint Review is made obsolete.

So why do we have the Sprint Review?

What does the Scrum guide say about the Sprint Review?

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.“ — SG
“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.“ — SG
“Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.” — SG

A demo is usually part of the Sprint Review. It doesn’t have to be though.

The Sprint Review is an important inspect and adapt event. As is every event within Scrum. The Scrum Team and the stakeholders discuss what was planned in the Sprint, what was done in the Sprint, what hasn’t been done in the Sprint, what was learned, what challenges we faced and how we resolved these and what to do next.

The Sprint Review is the perfect opportunity to also align with stakeholders that you don’t see or speak daily. We have a few teams within our company that on average have 50 stakeholders participating in the Sprint Review. How cool is that, to have such a platform for the work that you did and plan to do!

You can consider the Sprint Review as a ‘marketing’ moment where you can show something with pride. You could even include a ‘Oh…just one more thing’ moment that blows everyone’s socks of.

The Sprint Review will result into a revised Product Backlog and probable items for the next Sprint. Resulting from conversations with all the stakeholders. Not only the ones that you work closely with. And this is key.

The Sprint Retrospective

The pain

Many people have said to me that they hate Sprint Retrospectives because they are rant sessions. The Scrum Team members complain about stuff that has been holding them back and every retro is a copy of the previous one. Every time the same issues are discussed and nothing is resolved.

Others tell me that they do retros on the spot. Whenever something happens they gather together and determine what they can learn from the experience. This way they can make the Sprint Retrospective obsolete.

Again a great practice (retros on the spot), but that doesn’t mean there is no use for the Sprint Retrospective.

So why do we have Sprint Retrospectives?

This is what the Scrum Guide says about the Sprint Retrospective:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” — SG

It’s inspect and adapt again. Look at how the last Sprint went and create a plan how to improve. It is not only looking back, it is also about doing something to change things for the better. Don’t be over-ambitious. Take small but concrete steps. This will be the best bet to success.

Do also reflect on what went well! This is important. Especially when something has improved compared to the previous Sprint.

The Scrum Team should discuss how they can improve or enhance their way of working. These improvement items can be input for the Sprint Planning. It is important to leave room in the Sprint Planning for improvements of your processes and practices.

If you failed at improvements, it doesn’t mean you should stop doing it. If the team couldn’t do it, they just couldn’t do it…YET. It means they have to try again and get better at it.

Another important part of the retro is the following:

“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”” — SG

An aspect that is often forgotten. Inspect your Definition of Done. Is it still valid on all points? Can it be extended? Can it be refined? The Sprint Retrospective is THE event to tackle this.

You may argue that you can have these observations and improvement implementations at any time, you don’t need a separate meeting for that.

My response to that is that this needs to be a formal event in one shape or another. I have seen too many occasions where people said that they really should sit together and reflect upon what they just had experienced. In the end it often doesn’t come to that, because they moved to the next situation.

The Refinement

The pain

The Scrum Team has endless refinement sessions. All stories from the backlog are discussed in detail and estimated. This includes many items that the team can’t possibly pick up within 1 or 2 Sprints. It also includes items that probably will never be picked up. And the people know this. This kills motivation.

So why do we have Refinement sessions?

This is what the Scrum Guide says:

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.” — SG


“Refinement usually consumes no more than 10% of the capacity of the Development Team.” — SG

You wish to have items ready for the next Sprint. And it is good practice to have some more refined so that you don’t run out of refined items.

And that is totally in line with the whole concept of Scrum: inspect and adapt. Work on an item, get feedback on the item, adapt your backlog based on the feedback. Don’t plan too far in advance. This translates to: don’t refine too many items in advance.

It makes no sense to refine the entire Product Backlog. You can bet your money on the fact that those items at the bottom of that (too) long backlog will never be picked up.

Final words

Scrum may seem meeting-intensive. If you deep-dive into all of the events you will notice that they are essential.

The Scrum Guide elaborates on the importance of the events as follows:

Each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.” — SG

If the events seem a waste of time to you: investigate why this is the case. There is a big chance that the event isn’t used for what it is intended. Make it an effort to repair this. There is plenty of information to be found to improve all of the events within Scrum.

But I can already give you this:

It might be worth-while to aim to make meeting rooms obsolete. The Scrum Events are supposed to be active workshops aimed to learn something (inspect, training, improvement), where you have alignment and raise transparency and where you create a concrete hands-on plan (adapt). A classic meeting room setting may not be the best way to achieve this.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

My twitter profile is https://twitter.com/WJAgeling

A big thank you to Sjoerd Nijland for giving me the opportunity to write the article as part of the ‘Kick in the Scrumbut’ series.

Next episode:

Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!

My twitter profile is https://twitter.com/WJAgeling

Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!

We run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.