User Story Focused Daily Standups

Agile development is very near and dear to our hearts at Our engineering and operations teams use a combination of Scrum, XP, and Lean practices to guide everything we do. From the very beginning, we approached our adoption of Agile the same way we approach our code: gradually improving by inspecting and adapting. We constantly tune to address challenges, complications, and inefficiencies and always tailor to best fit the team. Some of the tweaks we try work, some don’t, but we are always trying to improve.

Ray missing daily standup in the bathroom

Story focused scrums do not reduce the importance of having all team members present and on-time (as Ray found out here)

The Daily Standup

One facet with which our engineering team recently tinkered is how we run our daily standups.  As a core Scrum and XP tenet, we have consistently used the daily standup meeting to ensure effective team collaboration.  For a long time, we did our standups in the traditional person focused manner with each team member answering the three questions:

  • What have you done?
  • What will you do?
  • What are you impediments?

and then passing the conch to the next person.

Why Person Focused Standups Weren’t Working

As our team grew, and the granularity of our user stories improved, the nature of our development changed.  There was no longer enough work on a single story to occupy the entire team and thus we began to parallelize.  We also noticed that many stories were staying active for longer periods of time and developing what we began calling “task tails” (where a story stagnates with the number of unvalidated tasks remaining consistently low for many days). We identified two primary reasons for the occurrence of task tails:

  1. Low code quality resulting in QA finding a trickling but steady stream of bugs
  2. Developers moving onto other stories when a story appeared to be close to done but was not actually done

As a result of these factors, our standups became confusing; a person often talked about a different story than the previous person and this ascertaining the current status of an individual story became difficult. Instead of focusing on what was needed to finish the active stories, the focus was on what each person was doing or about to do. A subtle distinction but one that was increasingly problematic.

Once we recognized the regression in the effectiveness of our daily standups, we worked to figure out how to adapt the standups to how our development had evolved.  What resulted from these discussions was a decision to try changing the standups to be focused on stories, not people.  If it made the standups more productive we would keep doing it. If the standups did not improve, we would try to find another way.

What a Story Focused Standup Looks Like

At the beginning of the next iteration, we made the tweaks. Instead of iterating over the people in the team, we began iterating over the active stories on the board. Each person who worked on the story over the previous day or plans on working on the story over the coming day answers the three questions, but only about the story currently in focus.  If a person has worked on multiple stories, they will talk multiple times.  The scrum master keeps track of who has spoken and who has not. If, after going through all active stories, someone hasn’t spoken, it is usually a glaring indication of impediments. The scrum master then specifically asks these people to answer the three questions which usually gently coaxes out the impediments.


In this case, the change had the desired effect. Focus returned to what we needed to complete open stories and impediments that prevented a story from being completed quickly surfaced.

In the four months since making the simple change to story-centric daily standups, we have noticed our daily meetings are more efficient, easier to follow, and more useful for everyone. This improvement is not only noticeable by the team, but is reflected in our per story and per sprint burndown charts. If your team is having problems similar to those we faced, we recommend you give story focused standups a try.

If you are looking for more analysis of person-by-person versus story-by-story standups, here are Mike Cohn‘s expert thoughts on the matter: Should the Daily Standup be Person-by-Person or Story-by-Story?

  • Digg
  • StumbleUpon
  • Facebook
  • Twitter
  • Google Bookmarks
  • DZone
  • HackerNews
  • LinkedIn
  • Reddit
  • Guy Murphy

    Firstly if it works, it works, and you’re saying in works for you so nice one!

    In my view however the daily stand-up is the teams meeting and a chance for each individual in the team to give their experience, and their perspective on their development. I see the 3 questions as simply an aid at giving the more retiring individuals a framework in which to speak, but essentially it’s a chance for the team to talk to each other about whatever it is the team feels it needs to talk to each other about.

    I’m wary, but I’m also curious enough to speak to my team about it and see if they might fancy trying it.

    The biggest improvement we had recently to our morning stand-ups was when our Scrum Master recently left. We now gather around a pod of desks of one half of the team, some of them are sat, and we tell each other what we’ve been doing, and by the end of the 15min the format has broken down and we’ve worked out in a babble of chatter how we’re going to cooperate with each other that day… Before we tended to report to the scrum master.

    I prefered Agile when it was less about squeezing out every ounce of efficiency and more about promoting pragmatic, iterative and user/developer focused development rather than savvy micromanagerial theory.

    Tastes vary however, and I’m merely experssing a personal taste.

  • Some SM

    I once worked in a bi-location team, where one side really wanted the daily scrum to be person-by-person because they were good little soldiers that focused on their task and their task alone, and the other side that really liked story-focused daily scrums because it gave purpose.
    To me the “3 questions” of Scrum are by far the worst well-formulated of all the framework.
    To me it should be:
    – PBI (Product Backlog Item) driven and for each PBI:
    * who made any progress on this story and what are the next steps for it ?

    Don’t ask if there are blockers… it just tells the people that you think they are too dumb to tell if they are blocked.

    One particularly good advice is to have someone from the development team responsible for the story progression, so that at least 1 person cares. It shouldn’t be necessary, that’s for sure, but in large teams (6+) responsibility gets so diffuse that you could work for years without anyone feeling the need to be empowered (it’s easier to blend in a large group).