I’ve read quite a few blog posts lately regarding software estimates. Should we estimate epics, stories and tasks or not? Are estimates useful to software development teams or are they a waste of time? Do estimates add value to the development process or are they inaccurate and misleading?
As is often the case, the answers depend on your context. For example, an experienced team working in a familiar environment will find it easy to accurately estimate new epics, stories and tasks. A less experienced team working in an unfamiliar environment will have a difficult time estimating anything reliably.
Are estimates worth the effort?
If a development team’s estimates are unreliable, is it worth the effort? Yes and no. It may be worthwhile as a learning experience if nothing else. The team needs to have some idea of how complex new stories are. However, it’s probably not worth it from a business planning perspective. Businesses need accurate information to operate successfully.
Let’s look at this from a different perspective. I think we can agree that small activities are easier to estimate than larger ones. For example, if I ask you how long it will take to add a confirmation dialog box to a web form, your answer will likely be very precise. If I ask you how long it will take to create a complex database query and display the results, your answer will likely be less precise.
Keep user stories small and simple.
So, perhaps the real issue isn’t whether to estimate or not. Perhaps we need to think about what’s being estimated and how the estimate is being delivered. If you want your estimates to be reliable, your best bet is to derive stories that are small. In fact, if the stories are small enough, why bother to estimate them at all?
I recommend getting your sprint backlog stories down to one or two days of work. If you have 10 stories, you’re in the range of 10-20 days with 15 being the most likely. Want to be more accurate? Ten stories that are each 4-8 hours of work amount to 5-10 days in total with 7.5 being most likely. Worst case? You’re a couple of days late rather than a week or more.
By keeping user stories small and simple, estimates add little value. Some will argue that estimates are needed to derive a final delivery date for the project. Not true! The business establishes the delivery date. The software development team does the best it can to complete as many stories as possible within the time allowed. That’s how agile software development is supposed to work.