1) Morning scrum meetings can drag on if not properly managed. Changing the speaking order each day and having members voluntarily lead discussions can make meetings more dynamic. 2) When reporting status, team members should follow a consistent pattern of discussing work completed yesterday, work planned for today, and only bring up problems if help is needed from others. 3) If remote, send a pre-meeting email with your status. In meetings, keep reports brief and under 5 minutes, avoiding deep technical explanations unless necessary. Signaling "take it offline" prevents side conversations from dominating.

1. Good practices to make morning SCRUM meetings
more effective, more enjoyable and shorter in time
7 TIPS FOR MORE EFFECTIVE
MORNING SCRUM
Andrea Tino
#scrum #best-practice #improvement#agile #how-to #7

2. after:
of morning SCRUM meetings, this is what I learned...
YEAR MEETINGS MINUTES1 300+ 4500~

3. WHAT’S THE PROBLEM?
Morning SCRUM meeting is a crucial part in SCRUM when
adopting Agile methodologies, however sometimes these
meetings tend to go in the wrong direction.
What should I say?
What should I focus
about when reporting?
What should I NOT say?
What should I try to
avoid?
How should I say it?
Should I enter in
details? How much?
SCRUM meetings can take long as people have
things to report. This is inevitable as the purpose
of morning SCRUM is making the whole team
aware about who is doing what!
Many people, stuff to report

4. DO NOT START ALWAYS FROM THE
SAME PERSON!
It can be an habit to always take same positions and having
one member start reporting.
CW or CCW? Up 2 U!
Do not jump, follow
the order.
1
#1
#3
#5
#2 #4
When starting, avoid standing always in the same spot.
Changing perspective changes the way you speak sometimes!
Change your disposition
Being told to start is not bad, but
always having a member
volunteering to start is better.
Next time another member will
volunteer for obligation towards
those who preceded him.
Volunteer to start

5. ALWAYS FOLLOW THE SAME
REPORTING PATTERN
There is a good way to report stuff, and here is how
you should do it.
2
Start first talking about what you
did the last day.
You did...Yesterday
I did
Today
I will do
Then move to what you plan to
do in the current day.
You will do...
25
MAR
26
MAR

6. IF YOU CAN’T BE THERE, SEND AN
EMAIL WITH YOUR SCRUM STATUS
Morning SCRUM should always have all members
present, also when they cannot be physically there.
3
Send it anyway
Some like sending the email in any case...
+My-TeamTo:
WFH & SCRUMSubject:
WFH, find my SCRUM status below :)
Did yesterday:
- Fixed bug #2354
- Closed collab. req.
- Worked on #5422
Will do today:
- Keep working on
#5422
- Pick another bug
Body:
Prior to SCRUM, send an email to all
members with your SCRUM status in it.
SCRUM MailBla
Bla
Bla
Bla ...

7. MAKE IT SHORT, NO MORE THAN 5
MINUTES EACH
SCRUM should not take too long. It is good practice
using no more than 5 minutes.
4
Be considerate
of others
If you exceed in
time, the next
member may feel
under pressure and
use less time!
Report what you need but
remember that your time is
limited and you should not
take more than 5 minutes.
Briefly...
Remember you need to
make your colleagues aware
of your progress, they do
not want to hear the whole
story. That’s why 5 minutes
are enough!
You have time

8. REALLY NEED TO REPORT A PROBLEM?
Sometimes team members tend to focus a lot on problems they had and how
they solved them. But, is it necessary to report this?
5...
Report!
Let the Team know
where you’re headed.
Report!
Describe it,
ask for help.
No action!
Keep it for
yourself.
Your Team wants to
know which direction
your work is going to.
Problems should be
reported only if you
need help from others.
Overall progress
Problems
Need help
<else>

9. REPORT A PROBLEM? KEEP IT SIMPLE!
When it is necessary to report a problem to ask for suggestions try to describe it
without detailing things too much.
...5
Don’t go deep down,
stay on the surface!
Yesterday the website went down
because process X uses file Y and
after parsing it does not release the
XMLParser causing the object to
retain memory. A code defect also
causes the parser not to dispose of
memory at destruction time.
I spent the whole day trying to fix
the memory leak issue. We rely on a
virtual method which gets called at
construction time, but the virtual
table is not ready at that time, so I
moved that dependency using
injection thorugh a function pointer.
What happened What you tried
Yesterday the website went down
because process X does not properly
release memory.
We rely on polymorphism at
construction time, I fixed that issue
and deployed the process again.
Those are your
colleagues, no need to
explain technical stuff,
they already know!
Do not explain what’s
obvious!
Please don’t bubble
about how much time
you struggled on fixing
something, everybody
does every day :)

10. HOW TO “TAKE IT OFFLINE”
When you see things are getting longer,
just take it offline!
6
When you start a 1-1 conversation, it is always a
clear signal to take that offline!
No long conversations
We should not fix
that bug!
High regression risk
but we need a fix!
Let’s deliver it as a
patch after release.
But we changed
our release cycle,
gonna be too late!
!!!
TIO! When you are not addressing
the whole team.
TIO! When you start detailing stuff
too much.
TIO! When your colleagues are
not following you anymore.

11. AVOID CHAOS, ONE AT A TIME
Especially in the beginning, people might
start different conversations. Avoid it!
7
Do not start talking with somebody
leaving the rest out of the
conversation. At SCRUM you need to
share with the whole Team!
Avoid micro-talking
Bla
Bla
Bla
Bla
Bla
???
???
Bla
Bla
Bla
Bla
Bla
Bla
Bla
Bla

12. ENJOY SCRUM!
SCRUM happens in the morning, have a nice
SCRUM time to start a better day with your Team.
:)
Bla
Bla
Bla

13. The End
THANK YOU
Twitter: @_atino
E-Mail: andry.tino@hotmail.com
This work is distributed under the Creative Commons
Attribution-NonCommercial-ShareAlike 4.0 International license.
This work includes edited arts by
Microsoft Clip Art.