The story-focused Daily Scrum

stand-up-meeting

We are all familiar with the standard Daily Scrum, or Daily Standup, template, where the team gathers around the story card wall or Kanban board and each individual shares what they did yesterday, what they will do today, and what help they may need in order to accomplish their daily goal. This is an effective way for the team to reset at the beginning of each day during the Sprint, and share how their work is progressing. Some teams at my workplace are following another method, and I think it works better.

My issue with the traditional standup is that topics are too focused on the individual, and not the work of the team—What I did yesterday, What I will do today, etc. I think this assumes that after yesterday’s Scrum, everyone went back to their cube and didn’t talk to each other again until this morning. We know what you were working on yesterday, we were there collaborating with you on that work. The other issue is that more than one team member might have been working on the same story, either as a development pair, or maybe as an analyst providing a peer review. There are only so many stories on the card wall at once, and in the team member focused Scrum, we might be talking about the same work twice or more. How many times have you seen one developer give an update, and the developer next to him says “Ditto” because they were working on it together.

I think Scrum teams may be missing out on an important discussion opportunity—how is the work of the team progressing through the current Sprint? Is the story progressing toward completion? Is the story blocked? Don’t get me wrong, if you, as a team member are stuck, or need help, we need to know, so we can talk about it after the Standup. This type of personal work sharing is still happening in my office, but the standup focuses more on the team’s goals, which is completing the work that they committed to at the beginning of the Sprint. Every team member is committed to success, and for that moment in the morning, everyone knows where each story stands in the iteration, not just what they are working on that day.

Story-focused Daily Scrums

In a story-focused Scrum, the team reviews each story-in-progress on the wall, one by one, and the team members that are working on it can share their updates or blockers:

Scrum Master: “Story 127: As a Customer, I can place any item in my shopping cart so I can purchase them at once in a single transaction later. It’s in Development—who is working on this one?”

Developer 1: “John and I worked on that yesterday, we will complete it by lunch and be ready for a quick review with the Product Owner before we move it to Testing.”

Developer 2: “Yeah, and we need to talk to who is working on the database as well. I have a few questions.”

System Tester: “Hey guys, can you grab me for that review with Sarah? I’d like to make sure my automated scripts cover everything all you did.”

Scrum Master: “Next, we have Story 132…”

This ensures that each story is discussed, like a little collaboration session for each card, with commitments to meet up after the standup for a quick JAD if needed. It would be a very different discussion if each team member (who might not be standing next to each other in the order of speakers) shared their own perspective on the story. It might be hard for the team, or the Product Owner, or any stakeholders joining the Scrum meeting, to piece together a complete narrative of how that story card is progressing and what help might be needed.

I have watched teams walk through the card wall forward and backward, talking about each card—starting at the Done column to celebrate how many story points have been completed in the Sprint so far, and moving to cards closest to complete to talk about first; or starting by quickly hitting the prioritized Backlog as a review prior to talking about work in progress.

Pros and cons of a story-focused Daily Scrum

Daily Scrum meetings aren’t supposed to be status meetings, they are daily commitment meetings. In a story-focused Daily Scrum, the team needs to be cognizant that they are communicating and collaborating with each other, not reporting a story-by-story status to the Scrum Master or whomever else is attending. Each team member needs to be accountable and committed to their work and the rest of the team, and the traditional Daily Scrum template ensures each team member has a chance to share their contribution every day, ensuring team members are accountable. I get that, I really do, but I think there is a really good opportunity for us to focus more on the work as a team, rather than on individuals and what they are each doing. I don’t think this contradicts the fact that we value individuals and interactions more than processes…, think of the team as the individual here. Then again, the traditional Daily Scrum can easily turn into an individual-by-individual status meeting as well if we aren’t careful.

What do we do with blockers?

There are internal blockers or questions, like with our Developers above, and there are external roadblocks that impact the team, such as dependency teams working on related code, shared development and testing environment issues, or design questions for an Architect that doesn’t sit with the team. Internal blockers are easy to discuss after stand up, but an external roadblock uncovered by a team member becomes a team roadblock. A good practice is to discuss those blockers every day if they haven’t yet been resolved, to ensure that they are visible, moving, and have action owners. One of the teams in my office starts with blockers each morning, before discussing the story cards—sharing updates on each, what items were closed, and making sure there is overall awareness of the issue, giving everyone a chance to creatively and collaborative address it.

So which Daily Scrum style is better?

As with all agile or Scrum practices, there is no one right way to do it (well, I’m sure some Scrum purists might disagree there), and the team should be quick to try new practices and discuss them in the Sprint Retrospective. The last thing I want is for the core Scrum cadence meetings to become stale, miss the point, or feel like something the team has to do; instead of something that the team feels is beneficial, important, and necessary. Give this a try and let me know what you think.

Advertisements

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