[mjlawson]

> But breaking down tasks provides (1) some certainty that you know a thing is achievable, (2) gives you a strong idea of what can be started immediately, and what can be run in parallel, and (3) hidden dependencies on other teams. This in turn leads to a better estimation.

I very much agree. I think the key in the OP article is "to the smallest details." In order to truly know how to build something, you need to build it in the first place. Worse, you'll end up with a load of outdated documentation that will either be abandoned, or take up more developer time to update when it inevitably conflicts with what's produced.

I tend to stop planning once I hit some "unknown horizon," meaning that any further planning is more or less built on well-intentioned speculation, or is bikeshedding at best. Past that, and I think you end up creating more problems for yourself.