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!
Have you read this? http://martinfowler.com/articles/itsNotJustStandingUp.html
Yes, of course. It is definitely a must read! Thanks for your comment.
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.
Pierluigi
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
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.
Yes, this idea has it roots in lean. It’s quite a mind shift for many people, to watch the work and not the worker.
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.
Best,
Ajie