Guide For Daily Scrum Meeting - Dos And Donts

Surprisingly, most teams following Scrum see Daily Scrum Meeting (DSM) as just a 15 min ritual – one where teams get together to exchange updates. And quite conveniently, an inordinate percentage of scrum masters tow the ‘update’ line. They use DSMs to merely tick boxes off – facilitating and collecting the aforementioned updates. Now this treatment meted out to DSMs – possibly the most important scrum event – is quite a pity.

The good ol’ DSM, my friends, is hardly a plain ‘status update’ event – it is a lot more, as I’ll go on to explain in the next few paragraphs. In this blog I will try to capture the true essence of a DSM, by way of a few key pointers. The focus being on how to conduct the event effectively, and what to avoid therein.

To begin with, have you ever wondered why a DSM is often referred to as a ‘stand up’? The moniker drives at succinct, focussed meetings. A quick catch-up that enables Dev team members to focus on the bigger picture, while collectively working towards sprint goals. The last thing you want is to waste precious time, by way of a long and unfocussed get-together.

DSM is a time-boxed event, for the development team to showcase and synchronize their work items with other team members. It enables everyone to share inputs on these work items, while also being able to help those facing barriers.

The purpose of sharing updates goes beyond publishing the progress made. It should also enable transparency and discussion of work items each team member is planning to work on. This offers the team a chance to visualize underlying dependencies and to offer help around addressing any impediments. The core principle here operates on planning, doing, checking, adapting, and communicating on a daily basis.

To help you to get the most value out of your DSMs, I have tried summarizing a list of things you should do and a list of things you shouldn’t do below. Please go through them and try incorporating them into your DSMs. We would love to hear your experience and feedback on this checklist, you can reach us at consult@benzne.com

15 key pointers that could help in conducting an effective DSM

1. Start your DSM with an ice breaker
2. Use burndown charts to understand the remaining work
3. Drive updates randomly through the team, or take the alphabetic route
4. Ensure that each  team member starts off with what he / she is responsible to complete
5. Ensure that all impediments are explicitly raised
6. Encourage team members to seek help from each other
7. Notify of items completed in the previous DSM
8. Announce items planned for the day – make sure everyone is on the same page
9. Most importantly, team members should notify of sprint items that are at risk
10. Plan completion of the remaining items in the sprint
11. Discuss with PO, any new items that have entered the sprint
12. Offer help in resolving any impediments
13. Move the work items to the pertinent status on your ALM tool
14. Hold off on technical issues until all team members have communicated their progress
15. All stakeholders should reserve queries and redressal of concerns till end of the DSM –  possibly barring the scrum master and Dev team members

10 Key pointers on what to avoid while conducting a DSM…

1. Delaying your DSMs more than a minute post the scheduled time
2. Stopping with merely asking for ‘status of the work’
3. Getting into technical discussion before the team is done understanding the status
4. Focussing solely on yesterday’s happenings – ignoring what is in plan for the day and impediments in line
5. Members outside of the Dev team providing updates
6. Delving  into resolution details during the DSM
7. Stakeholders leaving the event soon after completing their status updates
8. Assigning work during DSMs
9. Allowing stakeholders, apart from the Scrum master, intruding updates or discussions
10. Interrupting the team with issues that are not pertinent to the sprint backlog

Subscribe to our Youtube channel (Link) and Newsletter to never miss a new video, article or blog by us.

Sudha Madhuri
Agile Consultant