Rethinking the Agile Standup in the age of Slack

It is time to rethink the Scrum ceremony.  We should examine what actually happens in standups and adjust based on the activities and the enterprise availability of forums, chat, and time-shifted communication channels.

We can leverage emerging communication channels to improve communication and focus live meetings on tasks that can only be done well in live meetings.

The Scrum standup was created 15 years ago as part of the Agile revolution. One of the core practices is the daily standup where the team identifies the work for the current day and any impediments or blockers in order to remove them as quickly as possible. 


The classic standup expects each person to describe three things.

  • What will be done today?
  • What was done yesterday?
  • What is in their way today?
Teams often add other tasks to the daily standup.  They may problem solve, solution or schedule other meetings.  I'm suggesting that we can remove some of the ceremony using Slack leaving space for higher value items.

We should split the standup ceremony pushing the three "whats" to Slack.  The meat of the standup then becomes blocker discussions and backlog progress verification. The blocker discussions can be more disciplined because you will know the number of blockers or need help prior to the standup.

Problem resolution and corporate communication be the primary part of the Standup  The Scrum meeting can be used for other team functions and for problem-solving.

Agile standups often consist of two parts.  The first half is one of two flavors. 
  • Part 1 is the standup. 
  • Part 2 is where problems are solved
The 2nd half is really post-standup for specific interested parties. Both parts exist because they are needed. 

Option A is the classic Scrum standup with the three questions. These can get sloppy over time and become disconnected from specific backlog work items.

Option B has been adopted by many organizations, especially if they roll up reports or metrics to higher levels of management.  Stories need to be examined and updated during the sprint. 

Many teams actually run a mix of Option A and Option B standups. Doing this during some portion of the weekly standups is very common.

The daily cadence of the standup makes it useful for all types of communication and teams take advantage of that.  It is counter to the standup's charter but happens because teams need places to discuss organizational issues without having more meetings.

Standups are not about status. Status is for management, not the team. Status should be communicated in work items or in Slack. The team itself often sees less value in standups if they turn into status meetings or if roadblocks and impediments are ignored. 

We want to make effective use of the full team's attention in these high-frequency meetings. The goal is to resolve problems sooner, increasing velocity.

The standard 3 standup items move to Slack with a standard format.  
  • Tasks should include work items where available.  
  • Meetings should be included if work-changing decisions are possible.  
  • Work done yesterday should only be described if it affects others or changes previous decisions. 
The core standup should then be used for problem-solving, dependency discussions, and team administration.

Slack / Stand-up Breakdown

This slide shows one way of splitting and re-targeting the standup.

# team-standup
The slack channel used for people's actions and blockers

Standup Meeting
A reduced schedule of meetings where the team either walk through the backlog or handles corporate and team logistics.

The team Slack for everything not related to standup activities.  Troubleshooting , blocker traffic, and other work shows up here.


  1. This is great Joe. I want my team to experiment and find the right mix for us. A channel just for standup is a great idea!


Post a Comment

Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs