Zen estimation - bare minimum iteration planning
December 14, 2015 in Engineering philosophyI 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.
Liked the post? Treat me to a coffee