I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct."
Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning.
My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road.
Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier.
Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work."
Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.
Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning.
My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road.
Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier.
Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work."
Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-...
Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.