11 Hints to Improve Your Scrum Meetings


Minuten Lesezeit

Sei dabei und sichere Dir bis zum 31.05.2024 Dein Early-Bird Ticket!

September 8, 2011

Hol Dir hier das kostenlose Probekapitel meines Buchs

Klicke einfach auf den folgenden Link und melde Dich an.

I saw a lot of Scrum meetings out there, that are not more than a skeleton. Everybody is attending but nobody is participating. To improve such situations I collected 11 hints to improve your Scrum Meetings.

Daily Scrum

1 – Walk the Board

Instead of answering the „three questions“, which leads in most teams to answering only the first two questions, walk the board. This means, use your Sprint Backlog to talk about what is currently in progress and what is planned for today. That way you’re concentrating on the really important things, instead of talking about the past.

2 – Show what you’re working on

Pictures are often better than words. Show your colleagues what your currently working on. And yes, it is possible to still do this within the 15 minutes time box.

3 – Appreciate the Daily Scrum as a Mini Sprint Planning

The main reason for the Daily Scrum isn’t the reporting. The main reason for the Daily Scrum is to plan your work for the day. The meeting should be used to plan your next steps in towards your overall Sprint goal. Try to change the context of the Daily Scrum and use it as a Mini Sprint Planning meeting.

Sprint Planning

4 – Demand commitment

I know that in the last update of the Scrum Guide the commitment was alleviated, but I think I’m not the only one who thinks this is the wrong direction. At least in Europe I still think that the commitment is an important part of Scrum. That’s why I demand the commitment of every team member e.g. at the end of a Sprint Planning. Write your Sprint goals on a flip chart and let everybody sign it. Put it on the wall of your team room.

5 – Avoid big tasks

I believe every ScrumMaster heard this sentence more than once „This task is not splittable“. Bullshit! I’m convinced that 95% of all tasks can be splitted in smaller ones. Don’t accept big tasks, just because you want to finish the meeting and head to lunch. And this leads us to…

6 – Bring food

The Sprint Planning meeting is the longest meeting in Scrum. Avoid that the blood glucose level is going down and everybody wants to leave as soon as possible. Bring food!

Sprint Review

7 – Rehearse the Sprint Review

Nothing sucks more than an unprepared Sprint Review. Take your time and prepare the Sprint Review properly. If it’s the last day of your Sprint and a feature is still not running, skip it. Concentrate on what is working and prepare a great show. Your stakeholders will love you.

8 – Use the daily Scrum to plan the last steps

The last Daily Scrum should be used to talk about the last steps that have to be taken to reach the Sprint Goal. Nothing is more important that day.

Sprint Retrospective

9 – Define a responsible

At the end of a Sprint Retrospective you normally have a list of (a few) improvements for the next Sprint. But as long as nobody was assigned to the improvements, nothing will happen. I know there are exceptions, but having a responsible team member per improvement helps to keep the team commitment.

10 – Define a DUE Date

The same is true for a due date. You may decide, that all improvements have to be done till the end of the next Sprint, but there are tasks that will take longer. Set a due date for every improvement to help to track it.

11 – Make the results visible

I saw a lot of teams that put the results of their retrospective into a Wiki or an agile tool. The problem with this approach is, that nobody will see them anymore. Out of sight, out of mind. Put the results on a flipchart and hang it in your team room, so that everybody can see them. If a item on this list is done, put a check behind it. Another approach is, to add the tasks of your retrospective to your Sprint Backlog.

I hope this list is helpful. If you have other ideas to improve your Scrum meetings, I’d appreciate a comment. Stay curious!


About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. Marc,

    Great post, not only for the content but also for its practical usability.

    I’m partially disagreeing on point 6: while I’m perfectly fine in bringing in food for long meetings, I’m objecting to the fact the sprint planning has to be a long one. My current strategy is to anticipate as much as possible the sprint planning work by 1. reviewing the backlog and 2. having a strategic discussion on the content of the next sprint before reaching the sprint planning.

    In fact, I believe a long sprint planning is a smell for something that went wrong before the meeting.

    One of the major dysfunctions I’ve noticing in long sprint planning meetings is a sloppily defined, understood, estimated and prioritised backlog:
    – Badly defined => The team discuss on the actual text of the stories, how to split them, the dependencies, …
    – Badly understood => The team argues on what they should actually develop in each story
    – Badly estimated => The team should give some kind of commitment, but if they don’t believe in the estimates there will be a lot of time wasted on re-estimating. This is also a symptom of a badly understood story
    – Badly prioritised => There is no clearly communicated vision from the Product Owner, so the team start strategising at sprint planning
    – This all gets worse if the team happen to be dependent from an external expert who is not available during the planning: they are asked for a commitment, but in fact they don’t have the relevant information.

    Scrum defines the team has to do a backlog maintenance during the sprint (a.k.a. Backlog Grooming), and if this is done properly, the sprint planning meeting becomes a very short one – in fact my teams are often below 1/2 hour for a sprint planning phase 1 -, where the team confirms the decisions taken already during the sprint and update them with any variations that might have happened in the last few days.

    The sprint planning phase 2, i.e. writing the tasks, is usually a much easier one and, in fact, I don’t mind if the developers do that during the rest of the day and come up with the task definitions some time after, hence keeping the sprint planning even shorter.


    1. Hi Pierluigi

      I really love the idea of shortening the Sprint Planning. I think I’ll try it out with my next team. Regarding your list of dysfunctions: I think they are worth a blog post. I’m already looking forward to read it on your blog 🙂

      – marc

  2. Your ‘Walk the board’ idea supports the Lean idea of watching the work not the worker.

    In my experience the three questions are good initially for team members to start interacting with one another. When they get used to interacting it is good to switch over to walking the board; I have seen better flow of work and increased identification of impediments by doing this.

  3. Hi Marc,
    Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to „automate“ the daily standup meetings – with just a single email. If you like to take a look: http://www.30secondsmail.com.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche