Monsters and axe murderers lurk around every corner in horror movies, but when it comes to agile workplaces, estimation is the devil for which you better keep your eyes peeled. Although teams do tend to see some improvement from using agile practices, Ron Jeffries writes in an article that these teams could stand to improve much more if they did not stifle themselves with so much estimation.
The first thing teams should not do is collect a list of definitive project requirements at the beginning, since the beginning of the project is when the project is least understood. Proceeding to estimate when the project will be finished is just as problematic, as the date established will be based on incomplete data and designed to give the developers leeway in figuring out when the actual finish date will be. Agile processes tend to lean toward short iterations that forecast the completion of small projects, because small projects are the ones most reliably forecast. Pressuring teams to take on larger amounts of work is a mistake because it demands more fuzzy estimation, but when management pressures teams to take on more work anyway, the estimations that they demand the team to stick to become like “promises” that cannot be broken.
There are some roundabout ways to get practical use out of estimation though. When you are approached with a new project and asked for a budget and time estimation, the best thing you can do is turn around and ask them what budget and timetable they want in the first place. Then you can decide right away if their parameters are plausible for you and your team. Being able to add up how much work can be accomplished in a given iteration is vital to accepting a workload that will satisfy the most people involved in the business. But if you find yourself in a situation where you are taking a wild shot in the dark trying to conjure up an estimation anyway, Jeffries offers up what he refers to as the “Five Card Method” for help:
Consider the product idea and divide the vision up into about five major topics. Each topic should make business sense: don’t divide it up in some technical way. “Online Bookseller” breaks down into, oh, maybe “Have info on a huge number of books,” “Search, find, and recommend books,” “Shopping Cart and Billing,” “Back-end Picking and Shipping,” “Reporting and Accounting.” Who knows? Find your own five. Can you estimate any of those five now? You may know a lot about shopping carts and have a good idea how long it will take. If so, estimate those items. For each item you couldn’t estimate, break it down into about five more smaller ideas… Generally, within a couple of levels of breakdown, we come up with things we can estimate. Use whatever means of estimation you like.
Jeffries believes the best case scenario is to skip estimation altogether and just allow for experimentation with great new ideas, but he knows letting go of estimation may be difficult. After all, the devil has a way of making the wrong choice seem alluring, but for the sake of your team’s soul, resist it as best you can.