Daily Standups in Scrum – What’s the purpose again?

Have you ever seen heated blogs, posts and forum discussions around how evil/great Scrum daily stand-ups are?

Under the skin of these discussions I’ve witnessed some recurring viewpoints. Some angles demonstrate a god-complex or a big-brother conspiracy fear, more sane angles appear to lose the fundamental purpose with comments like “It’s a waste of time, the team can check the source control check-ins to see what I’ve been up to”. These angles miss the point – It’s all about the team. Not everyone is as amazing as the Most Valuable Player, not everyone is a great communicator, not everyone chats over a coffee in the kitchen to make sure everything is ok, not everyone checks with the testers before they check in risky code. The team is unlikely to reach it’s full potential if they don’t grasp what the daily stand up achieves.

Now, just saying “It’s all about the team” doesn’t provide enough of an answer for me, so I want to get to the bottom of the purpose of the stand-up and a good place to start is our Holy Bible, the Scrum Guide (2011). Praise the scrum god.

…[The Daily Stand-up is] for the Development Team to synchronize activities and create a plan for the next 24 hours.

This to me, is the most important point. Obviously we don’t create a formal plan, but through a quick discussion with the group we can identify quickly:

  • Impediments/Risks to completion.
  • What meetings are needed.
  • Who needs to be left alone, as they’ll be ‘in the zone’ today.
  • Who needs some pairing-up with complex code.
  • What needs testing today, or even tomorrow, so preparations can be made

Now, some may argue that these things can all be achieved without a Daily Stand-up. That assumes that everyone is capable or feels they have the authority to make those decisions, and that they’ve talked to the right person. Recently, some of the most crucial observations made in our Stand-ups have been made by the non-domain experts.

Daily Scrums improve communications, eliminate other meetings, identify and remove
impediments to development, highlight and promote quick decision-making, and improve the
Development Team’s level of project knowledge. This is a key inspect and adapt meeting.

Other than the elimination of other meetings statement – Bravo scrum gods! I strongly believe that the continual communication allows early detection of failure, and quick peer review of decisions. We possibly have more meetings than before, but they are of a higher quality, plus everyone is on the same page every day.

The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal …

The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

I’m less enthusiastic about this one, merely because a clear goal that aids focus has always eluded me. If the goal is “implementing the highest priority stories” (which are usually unrelated), rather than “improving aspect X”, then it introduces inefficiency in development and testing. If the goal is narrower and the team resists work that doesn’t aid the sprint goal, the focus and determination this affords could result in the high quality iteration Scrum promises. So, in summary, checking the progress towards the Sprint Goal is only as good as the goal itself.

… and to assess how progress is trending toward completing the work in the Sprint Backlog.

Monitoring the burn-down can be done at any time, so the assessment doesn’t have to happen in the meeting. The more important purpose is to raise the issue, and have the team come up with actions to get it back on track.

Development Team often meets immediately after the Daily Scrum to re-plan the rest of the
Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner
and Scrum Master how it intends to work together as a self-organizing team to accomplish the
goal and create the anticipated Increment in the remainder of the Sprint.

Toward the end of the sprint, the testing effort might need re-planning, but on a day to day basis we rarely re-plan the remainder of the sprint. Most of the time the Daily Stand-up is over, and everyone dashes back to their seats like drivers at Le Mans. Also, we don’t tend to pre-allocate the work. However, the Daily Stand-ups do allow the product owner to ask any team member how the goal will be progressed in the next 24 hours. Then, collaborative working tools will complete the picture, warts and all.

The Daily Scrum is not a status meeting, and is for the people transforming the
Product Backlog items into an Increment.

To me, this was the most contradictory statement when taken in isolation. In context it actually means that it’s not a status meeting for the Product Owner/Stakeholders. Obviously telling the team what you accomplished yesterday, discussing the burn down and what can be tested – is status. The main thing to note that this meeting is for the team, and no one else. Hence the pigs and chickens analogy comes into play.

So, in summary, the purpose is:

  • Quick synchronization of activities for the next 24hrs
  • Quick decision making,
  • Identifying impediments
  • keeping ‘on goal’

Please share your thoughts if you agree/disagree, as long as you leave the nerd-rage at the door!


5 thoughts on “Daily Standups in Scrum – What’s the purpose again?

  1. This is a great summary on the purpose and need for stand-ups, thanks. The normal dictation of a stand up is misleading to many of these purposes:
    -What i did yesterday, -What i’m doing today, -any roadblocks.

    For example, one thing I added, is telling us if you think you’ll have open cycles (keeping an eye out for 24+ hours too). Alternatively, if you’re behind.

    One of my greatest successes was when the QA team came in and said “we cannot regress these 100+ bugs in a week,” I, as scrum master, and several of my developers that had some spare cycles stepped up and we distributed remaining defects to developers that could regress assuming it wasn’t their own code (which is how I came in to make sure they were distributed correctly).

    Not only did we ship a successful product, the team was better able to understand ownership, and team camaraderie soared.

    So there’s also an emotional aspect to meeting with the team everyday.

    • Thanks for the insight into your methods Michelle.

      I am trying constantly to improve the meeting so that people answer “what did I accomplish” rather than “what did I do”. The vagueness of “do” means you sometimes get information that is too deep or too granular, and unhelpful to the purpose of synchronisation.

      Of course it feels slightly draconian or rude to cut people off, but I’ve made it clear that its acceptable for anyone to say “it’s too much detail” during the standup. Not sure it fosters good morale but does make sure people feel empowered and that feelings are aired.

      The one problem we hardly ever have is free cycles for devs, maybe we’re overloading the backlog!

      We do maintain a combined burn down but have recently introduced a separate dev and tester burn down. This is combined with a spreadsheet which details the hours each day people are actually available to work (holidays etc), helps us see when we are going to fail early, or where the capacity is. It has been useful on the odd occasion.

      If you have any more examples of where you’ve increased team spirit/comradery I would love to hear them.

  2. Great summary, should be added to the book as an appendix.
    @Michelle: Great closing of a summary with the ownership and camaraderie 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s