This might be good guidance to avoid getting too deep in the weeds and avoid starting work. Might even avoid the whole "waterfall with sprint" trap, but I'd argue it's quite important for the entire team to have an idea of where they are going, generally before you start work. Agile Roadmapping is a thing that works. Feature prioritization, generally, helps to get the highest value things out the door first, etc.<p>The team doesn't necessarily require those waterfally milestones - it could be as simple as a value delivery statement ("Fastest shopping cart west of the Mississippi" or something) - it doesn't have to be a whole big deal with specifics, but without it i'm not sure how you determine the sprint goals, let alone what the specific technical tasks or stories are going to be without that shared context.<p>Lastly, I'd definitely recommend some sort of longer-term roadmapping exercise up front to determine what the high risk things are so you can solve them first, and test the big hypotheses quickly. That would be a nice lean thing to do.<p>Plan the sprint, sure. Be militant about it if you want. "Shut up and plan the sprint!" But the sprint is not the goal. Delivering increments of value is the goal. The product owner looking at the sprint goal needs to know what they're trying build, and a longer vision can help.<p>I'm not sure the author meant to sound so short-sighted and maybe was expressing frustration around customers getting so wrapped up in the "plan" that they end up waterfalling / micro-managing to death, so I get the point, but there's a way to do this that doesn't sacrifice the plan, too. They probably know that.