Stop Planning Based on Guesses

I grew up in the mid-west where the roads are largely flat, straight and there is not much variation in the scenery. If you have spent any time driving through similar country you will know that judging how fast you are going or if you are making progress is challenging. As a child I quickly learned that if I watched the mileage posts along the road, I could judge my family's progress on any road trip we went on.

Early in my career as a software developer, I learned quickly that if I could communicate a sense of progress in my clients, they were much happier. How to show the equivalent of the sign posts going by became an obsession for me. I spent lots of time studying estimating techniques and getting good at decomposing my project deliverables into tangible tasks with estimated hours or story points. The trouble was that I was almost always wrong on estimates for individual tasks. How do you estimate something you have never done before, and likely no one else has done before?

I knew that if you decomposed the project into tasks and estimated the individual components the sum of the total would come out close, but the individual tasks were almost always wrong. The classic advice is to keep track of your actual time spent on each task so you could improve your accuracy for future tasks. This might work for tasks that get repeated on every project, but in software development, that is rarely the case. Besides, keeping track of time worked on individual tasks is a tedious and error prone process. One inevitably ends up allocating time at the end of the day. A second guess!

It is important to project when the project will be done and to show progress. What other methods do we have other than guesses?

The No Estimates movement seems to have some answers. I have been skeptical of this seemingly controversial thought of not doing estimates. However, after watching a presentation by Allen Holub, I have decided I don't like the moniker, but I do think the concepts solve a huge problem. In this presentation, Holub quantitatively illustrates that counting tasks is equally as effective as story point guesses.

I've written software to compile estimates for hanging drywall and dropped ceilings. There were no guesses involved, only measurements. The estimator measures the linear distance of a wall or a the square feet of the ceiling, selects the material they are installing and a predetermined calculation tells you how much labor and material will be required. It is not 100% accurate, but it is not a guess.

Imagine asking a team of drywall hangers to discuss a set of plans and tell you how many story points it was going to take to finish each room. I'm certain you would get an education on your intellect by the team and the person responsible for wages would want to know why the team was not hanging drywall.

The No Estimates method of counting stories is a quantitative estimate similar to the methods used by construction estimators use. It is not 100% accurate, but it is no less accurate than meditating and guessing. It also means your development teams are not spending time on something that doesn't add value.

 While the time spent guessing how long a task will take or how long you spent on it is wasteful, the time spent planning or decomposing your stories is extremely valuable. Spending the time to develop a solid understanding of what work needs to be done will increase the quality of the work and increase your ability to project when the work will be done.

It is relatively easy to put story points on a story that is not well defined. After all it is just a guess. Decomposing a story that is not well defined is not as easy and the lack of detail quickly becomes apparent through discussion with your team.

Showing stakeholders the signposts going by will always be important. Reducing the number of guesses you include in your methodology to show progress will decrease waste and provide the opportunity to spend more time delivering quality solutions that deliver value.