ad-hoc Planning

Myth: The Daily Scrum is when developers pick their tasks for the day

Variations:

• Daily Scrum is where planning happens

Category: Daily Scrum myths
Danger: Low

The basis of the myth

The Scrum guide says, "During the [Daily Scrum] meeting, the Development Team members explain: [...] What will I do today to help the Development Team meet the Sprint Goal?"

In some teams, developers will stand in front of the Story Board, and then spontaneously decide: "... hmm ... and today ... THIS one ...", deriving their behaviour from the Scrum Guide's direction to explain what to do today.

Why is it a myth?

This one is so close to truth that it could be true, but it's deceptively deviant.
Scrum does not say that developers should not have a plan until they come into the Daily, but that they should lay out their plan during the Daily, and adapt it where necessary. This ties right into the big bad dangerous overall myth "Agile people don't plan": Developers should be clear on their plan before discussing it, rather than winging it.

Assumption #1: Big Upfront Plan 
There is little harm done when the team has laid out a Big Upfront Plan of tasks during the Sprint Planning, except that developers cherry-pick tasks based on what they think is best, rather than work in priority order. It only becomes harmful when developers start completing tasks instead of delivering value.

Assumption #2: Scrum is short-sighted

Every developer should already have a clear idea on the next steps even before entering the Daily. The Daily Standup is not a breakpoint erasing history and opening a new page - it's actually intended to ensure everyone is still on the same page.

Assumption #3: Time-boxed planning is enough

Scrum suggests that the team has a clear plan for the day. Ad-hoc planning is OK when little planning is needed. But when necessary discussions get replaced with more or less random choices, the product success is endangered. The intended output of the Daily Scrum is a feasible, aligned plan for the next 24 hours. If more time is needed to create this plan, the unclarities should already have been discussed before the Daily.

Consequences

Lots of WIP

When developers cherry-pick their tasks rather than contributing to getting things Done, the Planning board will soon be cluttered with lots of started, unfinished stories. 

Unforseen impediments

When developers pick tasks without putting enough thought into them, the chance of failing the Daily Plan increases.


Postponing trouble

Developers often have an uncanny eye for spotting trouble, and when they simply pick tasks they think they can do until tomorrow, they tend to pick the ones with lowest risk first. The main risks of the Sprint are postponed.

Idle time

In some rare cases, developers will idle when they completed all of their tasks until the next Daily Scrum. That makes absolutely no sense: There is no reason to not do anything when the Sprint Goal is not met and there's work to do.

Remedies

Everyone on the team should be clear that Planning is not where you pick your tasks, but where you align your task plan with the rest of the team. An easy way to stop ad-hoc planning is to intercept developers before the Daily Standup and ask them what their plan is.

Keep an eye for Work in Progress. Put WIP limits on stories, not just on tasks. When a developer starts tasks on a new story while there are still open tasks for an existing story, scrutinize this decision.

If Daily Plans are considered an iron box (i.e., "I won't do anything I didn't state"), re-emphasize the agile principles of collaboration and technical excellence.