Skip links

Walk the board - making a daily scrum useful

February 24, 2014 at 12:20 AM - by Freek Lijten - 1 comment

Tags:

For a while now I've been dissatisfied with daily scrums. For your understanding, we actually have two of them at Procurios. One is with our developer team (developer outside of the SCRUM context, meaning backend-coders writing code in PHP and the likes) and one is with the project teams. Both follow the "way of the three questions". This is not the most ideal way though.

For the developer team one the three questions are actually pretty much okay, the aim of that standup is keeping in sync, signaling someone struggling for longer than necessary, etc. Not every dev standup is as valuable as the others, but saving someone from spending unnecessary huge amounts of time or stupid ideas is at least a weekly affair. For projectteams the daily scurm has a very different goal however.

So what is the goal of the daily scrum? The scrum guide from scrum.org states the following:

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Personally I interpret this as "The daily scrum is (re-)planning". Our team also considers this a status update to the product owner. Are we more or less on track? Did we over- or underestimate the amount of work? Are there impediments hindering progress? The status update might or might not be the original purpose of a daily scrum but has a positive effect on the insight in progress for the PO. 

With this in mind the three questions do not fullflill the goal good enough as far as I am concerned. Please note the "good enough" though, I'm not saying it can't work, I just feel it takes more to make it work and is in more danger of becoming a monotonous and boring affair.

The alternative - walk the board.

There is a reason why it is advised to have the daily scrum take place next to the scrum board. The board IS the sprint after all. So why do we stand next to it, all but ignoring our poor old good looking board? Walk the board makes the best of the board by having a user story centric daily scrum.

We still ask the three questions, but we ask the stories the questions. Since they won't talk back we still need to answer the stories for them, but the subtle change is quite interesting. Practically we walk the board from right to left (so from done, but not accepted, to just started). If a story is going well or went well we leave it alone. The handfull of stories that do have issues get more attention.

  1. What happened yesterday and why is this an issue.
  2. What will (or will not!) happen today and why is this an issue.

A bonus of walking the board is that you do not get a situation where a story is talked about in fragments. A bit by person A, a bit by person B. Another bonus is you literally can't forget a story (and with it some issue you forgot about?).

Small change, big change?

Funny enough, while this is not a huge change compared to traditional daily scrums, the difference is big. The daily scrum doesn't feel like we're performing a trick anymore and there is a more natural focus to what matters. A problem that might occur is that there is no natural moment to voice impediments that do not directly tie to a story anymore. To counter that, we end the daily scrum with some form of the question "anything else bothering you?". That is basically it. Small change, fairly big consequenses.

Share this post!

Comments

  1. JeffJeff Wrote on March 27, 2018 at 2:42:08 PM

    I know that in Kanban you walk the board from right to left. In Scrum does it matter wether you walk the board from the right or left ?

Leave a comment!

Italic and bold

*This is italic*, and _so is this_.
**This is bold**, and __so is this__.

Links

This is a link to [Procurios](http://www.procurios.nl).

Lists

A bulleted list can be made with:
- Minus-signs,
+ Add-signs,
* Or an asterisk.

A numbered list can be made with:
1. List item number 1.
2. List item number 2.

Quote

The text below creates a quote:
> This is the first line.
> This is the second line.

Code

A text block with code can be created. Prefix a line with four spaces and a code-block will be made.