Daily Scrum as Status Pulls

Illustrative Example

For many teams new to Scrum, the Daily Scrum is a core event that seems straightforward, but often presents numerous implementation problems when transitioning from a more traditional command-and-control process. An almost-universal challenge is differentiating between the Daily Scrum and a status report meeting. Here’s a typical example.¹

Analysis and Advice

When Daily Scrums Become Status Pulls

What is happening here is not an effective Scrum stand-up meeting; it’s just a traditional status pull. In fact, it’s probably worth dissecting this particular status pull to see why this particular “Scrum” process is failing. Two key elements that the project manager (not Scrum Master, evidently) is asking are:

• The original time estimate for the currently-discussed task.
• The actual time estimate for the currently-discussed task.

The only practical utility for this information is to determine whether estimates were on-target or not, or whether there are hidden process impediments that were not planned for in the original estimate. However, gathering this information in this particular way is not very agile because:

1. This information should already be transparent through the use of a Kanban board² or other framework process. Having to ask for it explicitly is a “project smell” that indicates a fundamentally broken project process or an undocumented objective.
2. Estimates are estimates, not commitments. As long as all stories that the team has voluntarily committed to perform during the Sprint are completed by the end of the Sprint, the individual story estimates (as opposed to the aggregate estimate) are not intrinsically useful except as part of a retrospective.
3. If the process is based on 100% utilization, rather than a throughput-based pull queue, then it’s neither Scrum nor agile. All agile frameworks require slack in the process; asking for daily deltas at such a granular level certainly implies an intolerance for the slack required by agile frameworks.

Now, the last item is particularly telling. The project manager wants:

• An explanation of why we were over or under the original estimate.

Getting better at estimating is a useful goal for any agile framework. However, one goal of Scrum is to ensure that the team does not over-commit; if there is extra capacity within the Sprint once all stories are completed, then the team can and should pull additional stories into the Sprint from the Product Backlog.

The question, as described, sounds a lot like stories are being assigned to the team for each Sprint, which is an epic fail from a Scrum standpoint. Even if that’s not actually the case, it’s another project smell³ that indicates that individuals are being “held accountable” (presumably by the PM) for the accuracy of individual story estimates, rather than for the team’s overall progress in meeting the Sprint Goal for that iteration.

Misestimating is an issue that should always be communicated clearly during Sprint Reviews, and used as a learning process during the Sprint Retrospective. However, the tone of the question implies that accountability for estimates is more important than the work itself, and diverts the Scrum Team’s focus from feature delivery to “C.Y.A. delivery.”

Using the Stand-Up to Coordinate Status

The following is partially correct, but misses the essence of what the
Daily Scrum is for.

[The Daily Scrum] is a meeting to go over developer needs and issues in a manner that is relaxed, and for the benefit of the developers (no one else).

The Daily Scrum is a commitment and coordination meeting between members of the Development Team, but as an information radiator it can benefit the entire team. It’s designed to ensure that the entire team is aware of impediments, what stories are done or not-done, and what tasks are ready to be pulled from one team member’s to-do list into someone else’s.

Despite being a meeting primarily for the developers, a Scrum Master or Product Owner can also gain value from the meeting. A well-run daily stand-up will give the Scrum Master a clear picture of any process issues that need attention, and whether individual stories are done or not-done. The Product Owner gains a sense of whether there are risks to the current Sprint Goal, timely insight into Backlog Refinement tasks for the next Sprint, and advance notice of when a Sprint might need to be terminated early.

It is often important that the Scrum Master and the Product Owner be present at the Daily Scrum, but primarily as passive participants. However, if the team is reporting to either of them, then the team is neither self-organized nor empowered to efficiently deliver value. Status-reporting to an authority figure during the Daily Scrum is definitely a framework anti-pattern, and one that deserves immediate attention.

Your Process Might Be Broken If…

Here is a short list of “project smells” related to status-reporting issues. If any seem applicable, address them at the next Sprint Retrospective.

1. If the team has so many stories on the board at once that a verbal report needs to identify the story by number, then the process is broken.
2. If the team has so many stories that a glance at the board doesn’t make it clear that things are moving from not-done to done in a timely manner, then the process is broken.
3. If the team is so large that a glance at the board doesn’t indicate who is working on what—or worse yet, requires cross-referencing with a separate spreadsheet—then the process is broken.
4. If the Product Owner’s only communication about the project or with the team is at the daily stand-up, then the process is broken.
5. If the Scrum Master can’t construct a burn-down chart from some combination of the story board, the daily stand-up, and ongoing communication with team members, then the process is broken.
6. If the Daily Scrum is not serving the needs of the team, then the process is broken.
7. If estimates encourage excuses or justifications rather than improved Sprint Planning techniques, then the process is broken.
8. If the team is reporting to any one individual during the Daily Scrum rather than cooperatively coordinating with one another, then the process is broken.
9. If your process is broken, but team members don’t feel free to directly address the broken process during a Sprint Retrospective, then your organizational culture is broken.
10. If your organizational culture is broken, and figuring out Who do we blame for breaking it? is more important than figuring out How do we collectively fix it?, then it’s time to dust off your resume.