Outstanding Standups

The daily standup meeting is one of the key agile practices. For teams that are beginning their agile transformation, this is an easy ritual to adopt.  For mature agile teams, it is an indispensable part of the day.

The daily standup usually goes something like this:

  1. The team gathers in the team room.
  2. Each team member answers three questions:
  • What did I accomplish since the last standup?
  • What will I accomplish by the next standup?
  • What things are hindering progress?

Daily Standup Ground Rules

  1. Everyone on the team must attend every day.  This includes the developers, QA people, the ScrumMaster, and Product Owner.
  2. Other stakeholders can attend but should not interrupt with questions or comments. Notice the absence of the “chickens and pigs” reference – that has been removed from the Scrum guide .
  3. It happens at the same time every day.
  4. Lasts for a maximum of 15 minutes – period.

Making it work

  1. Gathering around the task/Scrum/Kanban board helps to focus on accomplishments and work remaining for stories that are either in flight or coming up next.
  2. It is tempting to dive into solving issues or talk through requirements during the standup.  The ScrumMaster’s job is to remind the team that these discussions need to be taken off-line, ideally right after standup concludes. These types of discussions may indicate that the developers and Product Owners are not spending enough time together outside of the standup meeting.
  3. Since the Product Owner is a member of the team, they can be given some leeway to interject with questions, but it is important to recognize quickly if it is a discussion that needs to be taken off-line.
  4. Some teams fall into a rut where team members provide updates that are more of a “where am I with what I am working on” update rather than what has been accomplished and what will be accomplished.  This is gets to the crux of what the standup is really all about: team members re-committing to each other on a daily basis about what they will accomplish towards meeting the team’s commitments.
  5. Everyone actually stands up for the meeting.  This helps to keep it short.
  6. Rule of thumb: if people start leaning against the wall, then the meeting is getting off-track or running too long.
  7. If the standup becomes a free-for-all, use a token (e.g. a ball) that the speaker holds. When he/she has completed the 3 questions, they pass it to another random team member who has not had their turn.  Passing the ball randomly to the next speaker helps keep people tuned in rather than sequentially going around in a circle.
  8. New impediments that are identified in the standup should be added to the team’s impediments board immediately.


  • The daily standup is an opportunity for team members to recommit to each other.
  • Everyone should attend, and the meeting should last a maximum of 15 minutes.
  • The discussions should remain focused on the three questions.

Developers are from Mars, Product Owners are from Venus

Developers are From MarsJenny was a seasoned product manager who was growing into the Product Owner role.  She liked her additional responsibilities as Product Owner and the flexibility of the organization’s agile approach.  But after a difficult backlog grooming session she asked Tim, the Scrum Master, if they could speak privately. Imploringly, she threw her hands up in the air.

“Every time I suggested something in that meeting, the developers told me all of the problems with doing it. Why are they always so negative?  I also don’t think they really understand how complex some of business processes are. I’m worried that a key requirement is going to be missed.”

How should Tim respond to this? The key is in understanding the differences between how Product Owners and developers think and communicate.

Unprecedented access and communication

Remember the agile principle that states that “Business people and developers must work
together daily throughout the project?”  Before agile, buffers often existed between business people and developers.  A project manager, business analyst, or technical architect might have handled requirements gathering and posed questions to the users on behalf of the team. It seemed to make sense because they were better at switching between technical and non-technical discussions. Then agile came along, and all of a sudden users, product owners, and developers found themselves sitting around a table writing user stories, discussing detailed requirements and designing solutions. This created a new set of communication challenges…

A difference in perspectives

Writing code is a very intense, engrossing activity where the brain thinks in both logical and creative terms and attacks technical challenges from several angles until solutions are found. Defining requirements is geared towards brainstorming what the product can be. Because developers are accustomed to eliminating coding solutions that will not work, this thought process is instinctively applied to product design. What a developer perceives to be a logical approach to finding a design that will work can perceived as negativity by a product owner or user.

Solutions before requirements

While some developers are adept at hearing a business problem, formulating an approach to solving it, and breaking it down into constituent pieces that can be built into software, many do not have those analytical skills. Some developers are more comfortable in the realm of very specific solutions, and upon hearing a business problem, begin thinking in terms of how web pages should look and work.  Meanwhile, Product Owners and users are still thinking about shaping the underlying business processes, identifying user roles, defining and mapping the user stories, assessing the flow of the stories relative to the process, and determining how to logically approach the work.


  • As a Scrum Master, Tim needs to avoid letting people outsource their conflict to him.  That means bringing the Product Owner and developers together for a talk along with doing some individual coaching.
  • The Scrum Master can help the Product Owner understand why developers sometimes think in critical terms.
  • The Scrum Master can help developers understand what needs to be accomplished during the various types of meetings. Much of this is centered on having everyone understand that it is important to discuss things at the right level of detail at the right point in time.  This usually means that discussions should not get too detailed too soon. It also means reminding people when to focus on “what” should be built and not “how” it should be built.
  • For complex business processes, it may be necessary to add a systems/business analyst to the team. Analysts know how to discover and capture the nuances of complex processes and how to facilitate re-shaping them to fit new business goals.