James O. Coplien

The core of Agile is the ability to respond to changing product demands. To do that, the folks working on the product need to be interacting closely.

Scrum is agile at several time scales. We have customer collaboration and frequent delivery at the Sprint level. Sprints kick off at Sprint Planning, with the team assembling their work plan for the upcoming development interval. But Sprint Planning isn’t the last word. The team learns about the product—how best to implement its envisioned Increment—day by day. The Daily Scrum is a Scrum Team’s agile heartbeat where Developers re-plan their work daily.

Briefly, the event is an all-hands meeting of Developers that is time-boxed to 15 minutes. Developers re-plan what they will work on next until the next Daily Scrum and perhaps beyond. To be able to do so, they need to quickly develop a consensus view of the current state of the development and of whatever impediments might lie in the way. Some teams, especially new ones, might use the famous “three questions” to inspect the current state and the desired trajectory. However, those are neither sufficient for nor necessary to the Daily Scrum. And standing up? It’s a reminder to keep the meeting short. But the Scrum Police won’t ding you if you sit down: they didn’t stand up in the primordial daily meetings at Borland that inspired the practice.

Change is rarely continuous, but it is discrete at some granularity of time. Simply inspecting and adapting once every two weeks is too seldom. And although the product changes with every atomic development action, synchronizing too frequently is irritating and inefficient. Humans are creatures of rhythm, and days are a natural human cycle.

During the Sprint, the team is on a trajectory to achieve a Sprint Goal: an agreed, measurable benchmark that usually reflects a business imperative. The developers’ Sprint Backlog is a work plan crafted to meet the Sprint Goal. The Sprint Goal is so paramount that the Developers commit themselves to it, but not necessarily to the Sprint Backlog. If they find a better way to implement a feature during the Sprint, they can freely change the work plan. The team consults the Product Owner (PO) to change the forecasted scope if it enhances the chances of meeting the Sprint Goal.

The Daily Scrum is the Developers’ meeting. Should the PO or Scrum Master be there? Maybe. An immature team may need the guidance of the Scrum Master as to the scope and purpose of the meeting and to enforce the time-box and cut off side discussions to solve impediments or about other topics not directly related to meeting the Sprint Goal. An immature team may too easily succumb to micromanagement by a PO, so it may be best to defer any PO interventions until the team builds an adequate degree of trust and maturity.

Too many teams use the Daily Scrum as a plug-compatible replacement for the pre-Agile practices it displaces. It is not a reporting meeting. If there is something that developers need to communicate to the PO or Scrum Master, they can do that any time without having to have a meeting. It is not just to answer the three questions. It is not a group hug. It is a way for the team to mark daily progress and to inspect and adapt their way to delivering value by achieving the Sprint Goal.