Two Ways to Get the Most Out of Daily Stand-up Meetings

A daily stand-up meeting is an essential part of agile software development. It is a meeting which takes place at the same place and time every working day.

The agenda of this meeting is simple. Each team member must answer to three question:

  1. What did I do yesterday?
  2. What will I do today?
  3. What problems (impediments) prevents me from doing my job?

Seems simple. Right?

Nevertheless, I have attended to many daily stand-up meetings during the last six years and I have noticed that there are two common mistakes which people make during these meetings:

  1. Team members are not concrete enough which they describe their past and future actions.
  2. The daily stand-up meetings do not encourage the team members to focus on the right things.

Let's find out how we can avoid these mistakes.

1. Make it Concrete

A somewhat common situation is that people aren't being very specific when they describe their past and future actions. Let's think about the following situation:

Scrum Master: "Thank you Y. X, it is your turn to speak."

Developer X: "Yesterday I was implementing feature X and today I am going to continue the implementation."

The problem is that developer X isn't being very specific. In other words, it is impossible to know

  1. What did he do yesterday?
  2. What he is going to do today?
  3. When the feature X is going be finished?

Of course, the person who facilitates the daily stand-up meeting can solve this problem by asking additional questions from developer X. The problem is that this takes more time, and since daily stand-up meetings should have a time limit, this isn't the best possible solution.

The best way to solve this is to expect team members to be as specific as possible (but not too specific). If the developer X would have followed this principle, he would have said something like this:

"Yesterday I was implementing feature X. I finished the domain model and database migration scripts. I also created the required repositories and implemented the service layer. Today I am going to implement the web layer. If I don't run into problems, I will expect to finish this feature today."

This is definitely better than the first statement. It is concrete, it isn't too long, and it answers to all three questions mentioned earlier.

Be concrete. It helps us to spread information to our team members and notice problems as soon as possible.

2. Focus on the Right Things

If I notice that something is broken, I want to fix it right away. I have also noticed that most developers tend to act in the same way than I do.

Fixing broken things is not a bad thing but sometimes the thing which is broken has got nothing to do with the feature which is assigned to the developer in question.

This is a problem because it doesn’t help us to achieve the goals of the current sprint!

Luckily, it is an easy problem to fix. When a developer reports his past and future activities in the daily stand-up meeting, and the team notices that the developer is getting sidetracked, they should help the developer to focus on the right things.

And what should we do to the problem?

We should ask the developer to add an item to the product backlog.

Did I Miss Something?

You probably already guessed that I think that the daily stand-up meetings have two important goals:

  • Help us to notice problems by sharing information to our team members.
  • Keep us focused on the right things.

You might have different priorities and that is perfectly natural.

Like I said, the advice given in this blog post is based on my experiences. Your experiences might be totally different. If this is the case, I ask you to share your tips by leaving a comment to this blog post!

If you are looking for a way to improve the quality of your daily stand-up meeting, read an article titled It's Not Just Standing Up: Patterns for Daily Standup Meetings. It explains many useful patters for daily stand-up meetings.
4 comments… add one
  • Eddie B Jan 27, 2014 @ 13:36

    Great share... I currently working on a project that I realistically have no idea how long it will take to complete and my cto is asking "when will this be done?" I dont have solid date ... so - I have to explain what I've done and what I'm doing ... anything else would be a lie :)

    • Petri Jan 28, 2014 @ 21:37

      That is a great point. When I wrote that we should know when the feature X is done, I meant that we should have a rough idea about it. In other words, we should know if it is done today, this week, or never. Also, this information should not be considered as a work estimate. It is just a guess.

  • Revino May 21, 2015 @ 15:11

    Hi Petri. Thanks for this nice article. We figured out that standup meetings are great but
    needed improvement (they took a lot of time, de-focussed our colleagues and
    interrupted their workflows). Because of this we developed a SaaS tool to ʺautomateʺ the daily standupmeetings - with just a single email. If you like to take a look:
    Best, Revino

Leave a Reply