Zen estimation - bare minimum iteration planning

I think agile story estimation à la planning poker isn’t agile any more. It breeds too much verbal discussion that doesn’t lead to improving productivity. The ability to put down a number produces false confidence in expected outcomes by letting you wrap an unknown and undefined number of complications into a clean-looking (albeit higher) estimate. What you are really saying with that number is that you don’t know how long the task will take.

I made up a new way of estimating software development scope (as a thought experiment this morning). I call it… zen estimation.

• Scope is broken down into stories. A story is the business deliverable unit. Requirements are shared on the story level.
• Stories consist of tasks. A task is the unit of work. To start with, a story is treated as one task.
• Every task is worth 1 point. A story is worth the number of its tasks. So, at the beginning, every story is worth 1 point.
• If a story or task feels too big for 1 point, list its steps and break it down into several tasks.
• If a task feels too small for 1 point, wrap it up into the next task, and don’t dive into too much details next time.
• If a story feels too small for 1 point, you are underestimating the cost of testing and writing specs.
• If a story is too vague or needs investigation, do that investigation before committing to the scope. If that is not possible, add investigation as a separate task (now the story has two tasks worth one point each).
• How much is one point? You should always be able to finish off one point in a day’s work. (Knowing the variance in programmer productivity, it is vain to give a better definition.)
• If you end up with tasks that take more than a day, your planning is not good enough.

I feel like this approach to estimating would bring focus from fiddling with abstract numbers of “points” to planning out work into actionable steps.