1. Estimate (based on one-sentence title of feature)
2. Wait for approval
3. Find out detailed requirements
4. Design and document
5. Implement and deploy
If you try to do 3 first, you are not following the process. The process is touted as "best practice 2.0".
It's actually fairly easy to correct, but then it wouldn't be "best practice 2.0".
I disagree with him on "Normally, the way it works, is that your estimate is first scanned for odd looking or relatively large items. Hence be prepared to defend anything with “non-standard” name. Also split larger tasks so that all tasks have same order of magnitude, i.e. if most tasks take 2 days and one single task is 10 days be prepared to get drilled."
I believe generally you should actually communicate the hard parts of the project to people. You should actually communicate what about it is hard if you have any ability to do so, and you should state alternative risk management strategies you've turned down for what reasons if they ask about them.
Estimate the size of the problem in abstract units like story points, and do it in small chunks.