Daily Scrum— or How to Manage the Daily Incremental Update Timebox

Ahh, the Daily Scrum. Essential daily meeting or utter waste of time?

Let’s explore ways of optimizing this Scrum essential so that it’s useful and minimally impactful, shall we?

First, what’s the purpose of the Daily Scrum? Scrum.org proudly proclaims that “this event helps the team self-organize and fulfill their accountability (to achieve a successful increment)”. Bull crap.

You don’t need a meeting for this. In fact, because the human brain doesn’t work in a timebox, limiting collaboration to this (hopefully tiny) timebox is silly.

In order for this event to not waste everyone’s time, prep work should occur. And during that prep work, the team can determine if it needs the face-to-face meeting in the first place. If it’s not needed, don’t hold it!

Let’s do some math: At an onshore rates and median scrum team sizes, a 15-minute Scrum costs around $500 (including waiting around before and after). That’s more than an agile day’s worth of dev time! That’s not money well spent — and providing value to the customer (and the organization we work for is absolutely a customer of our efforts), is an Agile paramount.

An Efficient Scrum Model

Scrum folks recently removed the three “standard” questions from their Daily Scrum guidelines, which I also consider a step in the wrong direction. I’ve found these to be super valuable — but not as part of a meeting.

So what might an efficient Incremental Update model look like? To answer that, we need to explore what the goals of this update are:

1. Ensure that the mechanism used to track iteration progress is up to date. An individual can do this solo.
2. Identify any issues the team (part or whole) needs to address via face-to-face communication. An individual can do this solo.
3. Set daily accountabilities and determine if completed progress + envisioned progress is tracking toward a successful interation. An individual can do this solo.
4. Surface personal risks/blockers. An individual can do this solo.

Imagine the team has a tool like, say, I dunno, Slack available to it for communication (or Discord or a White Board, doesn’t matter). A mature Daily Scrum might look like this:

15 minutes prior to “Scrum Finishline”, all team members write the following into Slack:

1. What I accomplished since last Scrum. This is a bullet list of tasks completed with links to the tool you’re using to track tasks (linear, slack, rally, whatever). Mandating these links requires the team member to do the update and ensure accurate current task state. I’ve found mature teams do this as they go, so this isn’t a burden at all. And it ensures 100% accurate dashboards and tool hygiene.
2. What WILL I accomplish by next Scrum? Same format as #1, but predictive of the next sub-increment of time. This isn’t “what am I working on”, but team members actually holding themselves personally accountable for making measurable progress toward a successful increment. Providing meaningful bullets here means they’re continuing to think through what’s on their plate and they have a plan. So again, no burden here. And yes, again with hotlinks to tasks in the tool.
3. Velocity Factors. This isn’t just risks/blockers, it could be “Eureka, I started on this and realized it’s way easier than I thought!” What factors COULD affect your ability to accomplish the bullets in #2, above? Yep, taking your dog to the vet goes here, too.
4. Parking Lot. This is the essence of Scrum input! Parking lot is a specific request for face time. A well written parking lot item (and yes, this does take time but it saves the team time) says what you’re trying to do (expected behavior) and what you’ve tried and what you believe you need to move forward.

How To Use This Format

We’ve used Slack for years with this format and we find that more than half the time, meeting face to face is unneeded.

We DO support Social Parking Lot items because yes, a team is a collection of human beings and we need to connect on that human level to bond as a tight organization. So yes, social announcements are absolutely acceptable — and team members can choose to attend or not.

Team members do not abuse this, but I’ve found that such requests come in cycles — more after a team goes a few days without meeting face to face, less after social Parking Lot items are surfaced. Teams self-organize around this at the level that THEY need to connect as people.

We don’t need a Scrum Master to facilitate this. Any team member can wear this “hat”, and teams are very supportive when new folks step up to learn. After all, the facilitator is pretty much just reviewing a few things:

1. Did someone provide bullets for “What I expect to accomplish” yesterday which don’t match the “What I accomplished” today? If so, they didn’t meet their own expectations — we should understand why and determine if this will affect our ability to successfully complete the increment.
2. Are there any parking lot items which we need to meet and discuss?
3. Spot check (click links) on tasks to make sure hygiene is updated — but if this part of a team member’s Scrum input is generated by automation, this isn’t necessary either (and yes, we have automation that does this).

If the answers to these questions is “Nope”, then there’s no reason to waste that $500.

A Note About Meetings and Timeboxes and Brain Science

Minds don’t work within a prescribed start and end time. It’s not how we’re wired. Minds are associative and constantly working, and when they come up with an idea, our tooling needs to support recording and collecting those.

Which means that meetings don’t work the way we’d like them to work. Meetings ARE effective when body language, tone of voice, facial expressions and general non-verbal communication is desired (or essential) within a larger group.

This CAN apply to Daily Scrum. But, as my above discussion shows, it often does not.

The Author

Steve has spent quite a few decades in the software industry, progressing through higher level developer roles before transitioning to manager, product owner, scrum master and a myriad of other roles. All the while, he’s been focused on optimization — how can we, as software professionals and teams, eliminate bugs and deliver value faster?

After hundreds and hundreds of retrospectives, he’s developed the B3D (Behavioral Driven Design and Development) work pattern, a repeatable Agile/Scrum-based way to reduce or eliminate bugs and dramatically increase delivery of real value: properly working, maintainable, error-free code.

B3D seeks to take the mysticism out of Scrum and Agile, which are 5% solutions at best. And the metrics are impressive — 30+ teams over the past 10 years with before/after improvements of 2x to 3x velocity increases and 100x or better bug count reductions.

Speed + Quality = Possible