The "right" way to do stand ups

In my last post about daily stand up meetings dated(2011!!) I mentioned the standard format these typically take:

  • What did you do yesterday?
  • What do you plan to do today?
  • Do you have any blockers or impediments
We are all familiar with the approach. However, I often see teams losing focus of their progression against sprint goals due to executing the stand up poorly. 

If you find that going "round table" for individual updates is not providing any clarity on the progress of stories then it might be time for a change. Take this example:
  • Yesterday, I had some meetings. I caught up with my emails and i had a dentist appointment in the afternoon
  • Today I will catch up with Jane & Mike about Project Dilbert
  • No blockers
The format is correct BUT the content was of little or no value. Why? Because the update was not pertaining to any of the user stories in the sprint and the progress being made towards its completion.

My previous post states that we should "focus on progress". A scrum master should look at the above update and ask the team member:
  • What user story are you working on? 
  • How is that story progressing? Are you making headway? Do you need any help from another team member?
If the team has a kanban board then it should be obvious what story everyone is working on and the team member should provide a brief update about the story progress, not what they had for breakfast this morning, it's just not relevant.

The BoardWalk

The approach to stand ups that solves this problem is the "BoardWalk". The team goes through all the cards on the board (or at least the relevant ones, usually the ones in progress). Typically we go from right to left (focusing on stories that are closest to completion first) and we ask for a progress update on each story. 

This approach ensures that we focus as a team on the progress of the stories we have in the sprint. The updates the team members provide for each user story can still take the format
  • What did you do yesterday? (on this user story)
  • What do you plan to do today? (on this user story)
  • Do you have any blockers or impediments (on this user story)

But using  the Boardwalk all team members may not get a chance to share their update?

.... and that's OK!! 

If multiple people were working on a story and one can provide a relevant update as to how its progressing then that's OK, we don't HAVE to hear an update from everyone.

You can switch between stand up formats



As with everything we have passionate advocates for either of these formats over the other.

  • "Focus on the board walk its the only thing that matters"
  • "Go round table - we need to hear from everyone"

Both approaches are valid, until they're not.

  • Focus on the board is great for progress visibility but might eventually result in team member alienation.
  • Focus on the team members is great until we realise we are constantly missing our sprint commitments due to lack of progress visibility on a daily basis.

So here's the trick, listen closely... you can switch between these two methods. You could even try some alternative approaches if you're feeling experimental.You don't have to stick to the same format for ever and ever AMEN! It's good to change things up.

  • Try the standard way, if you feel updates are getting stale and uninformative then agree with the team to try the boardwalk.
  • If the boardwalk yields results but you feel like you don't hear from certain team members enough/ often then agree with the team to toggle back to the standard format

The extra benefit of switching back to the standard format from the boardwalk method is that you will find team members updates will now be more focused around story progress than they were before, due to the practice they have had when using the boardwalk method.


Comments

Post a Comment

Popular posts from this blog

Expanded EPIC boards

Image
What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or may
Read more

Things to consider when you want to change from Scrum to Kanban

Image
Scrum or Kanban? A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8% "Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following: We can't finish anything in a 2 week sprint There are too many meetings Our list of priorities keeps changing We can't plan for 2 weeks.  Our product owner keeps changing his/her mind They often feel like Kanban is a silver bullet because: It doesn't ask you to finish anything in 2 weeks It doesn't im
Read more

Moving beyond tasks

Image
One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakd
Read more