The daily scrum as an event map

This is another in the event map series. Following on from delivery mapping. This article will help you to see individuals and interactions and how the work over time connects to delivery of the sprint goal.

The scrum guide (2017 edition) suggests this format for the daily scrum

• 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?

Have used this a lot over the last 10 years, however it can become rather a status meeting.

Slight exaggeration here for dramatic effect. It’s 9am UK time. A distributed group across the UK and India are huddled round their screens sitting at their desks for their “standup”. They have meetings at 9am because it’s already 2:30pm in India and standups are supposed to be first thing and the rest of the day is “busy” with seemingly more important meetings. Also the manager wants an update after the meeting. There are several anti-agile patterns here but the one I see the most often is this one:

Scrum master goes round team in alphabetical order or whatever order they dialled in because that’s somehow easier because of the conferencing tool.

Dev 1: Yesterday I worked on Jira-1234 today I’ll be working on Jira-1235 and Jira-1230 is still blocked

Dev 2: Same story, different jiras

Test 1: I’ll pick up that Jira-1234 that Dev 1 has just told me they’ve finished and I’ll work on that today.

BA 1: I’m working on Jira-1236.

and so on. It’s effectively a status meeting and not even a very good one. But at least a few tickets moved during the “standup” so we can demonstrate progress! As a bonus we might have also stuck to our WIP limits. We’re agile right? Much of this is exaggerated, but I expect some of it may be familiar.

Excel’s got you covered here. We can see what’s going in via a table

The daily scrum gone bad

What works

1. It supports everyone articulating what they are doing and blockers
2. They’re probably familiar with the format
3. It suits kanban boards which have a lot of value in supporting flow and visualising bottlenecks

What doesn’t work so well

1. You can’t see the day visually and the flow of work
2. You can’t see the individuals and interactions
3. You can’t see the desired end state
4. You only get the snap shot state of the work now (or at some point in the past). There is no “when” on the board.
5. Sometimes difficult to see how the work relates to the sprint goal
6. The “did yesterday”, “doing today”, “blocked” is a bit formulaic
7. I wonder why people wait until the meeting to tell us what they did. Shouldn’t this be real time?
8. If you’re using jira it suffers from not showing collaboration. Instead you can only “assign” a ticket to one person.
9. There’s not much sight of what’s going on tomorrow in the event this might be useful.

How about representing the plan for the day as a map where we really see what’s going on and get those individuals and interactions visualised? The kanban board could then be mostly left to one side for the teams to update continuously.

So what does this mean for the daily scrum?

Try this format

Individuals and Interactions over time

This looks a bit like the movement of players in a field in football in visualising tactical moves. It might even be like scrum in rugby. So taking back scrum to its origin story.

This is a map which shows individuals and interactions over time, where the arrows join represent new interactions. Individuals and interactions are of primary value (rather than processes and tools which are of secondary value) and are from the first value statement of the agile manifesto. So here we see not only the individuals and interactions but there is also focus on the sprint goal and an indicated level of progress of the sprint goal over the indicated timescale. You can also get a sense of the velocity from the gradient of the line if this is important to you.

Hopefully this will help the product owner more than looking at tickets on a kanban board. I’m not suggesting getting rid of kanban boards, but they should be updated continuously rather just in the meeting. This format works alongside the kanban board to plan the activities of the day and facilitate coordination and focus.

This is still an evolving article, Feedback welcome