Estimation is Dead, Long Live Estimation!
Estimates are kind of a big deal. I’ve written about them before. (See here.) Last year was a big one for the idea of completely dropping estimation in the greater software development community. In July the twitter account @NoEstimates was taken on as an outlet for Woody Zuill specifically for sparking discussion on this idea. Ask any person in software development what they think of estimation and they’ll share their opinion with you. Mention the idea of not doing any estimation and it could get heated.
The “No Estimates” crowd has some good points. However I believe all out “No Estimation” is gouging out an eye to spite the face. What I feel the right answer is, and the one I have seen from various thought leaders this year, is “Valuable Estimates Only!” It just doesn’t roll of the tongue as well.
In our environment we do two kinds of estimation. On the surface it might seem odd. Estimation is for getting an idea how long something will take right? For us estimation has two purposes. Yes, how long something will take is one purpose. The other purpose is for the development team to better understand the requirement.
Our primary form of estimation is Planning Poker. This gets us an idea of how big a story is. On the surface we use T-Shirt sizes. The Project Manager and I translate them to story points for recording purposes. These story points relate to velocity. Later on we can compare them to actual hours and see how consistent our estimates are. More importantly Planning Poker gives the team a chance to dissect the requirements together. While we do maintain a 5 minute limit on the discussion, it is a loose limit. The discussion is the most valuable part of this planning session. It gives the team a chance to refine the requirement. No tasks are made as this is done to backlog items, but the team generally has an idea of tasks as they make their estimate.
Sometimes a requirement has to be brought back to the various business units by the analyst. (Proxy Product Owner for us.) Other times the requirement is one that the analyst knows is small and easy to understand. (This knowledge comes about by being a consistent team that has worked together for a long time.) In these cases we will try our alternate form of estimation. In this case an email is sent to the team members and we all reply to the analyst with our size estimate. If there is a large disparity in size estimate or there are many questions the requirement will be resolved via the primary estimation method. If there is a solid consensus then the estimate is done. In this case the value is largely for future sprint planning and backlog prioritization.
Depending on the primary value we seek we will do estimates one way or the other. The development team does not get a lot of value from the email estimation process. The cost is also minimal. The PM and analyst do get value. It allows for proper backlog prioritization. Without that estimation there would be no concept of what the backlog items “costs.” There are times that an item’s importance to the business changed significantly due to the estimate. Everybody gets good value from the Planning Poker sessions, but they have a higher cost.
As with most things Agile it really boils down to frequently inspecting and adapting to maintain the best value. If you are doing estimation that returns little to no value then get rid of it. If you have estimation in place that returns value then keep refining it. Next time estimation requests come around take a closer look at who is getting what kind of value from the process. This should be your guide in what to do, not the latest buzzword trend. That trend should just get you thinking.
What kind of estimation processes do you get value from?
