How Not To Scare Customers With an Agile Software Estimation

A friend you haven’t seen in a while says that he will be in Chattanooga for the day and wants to have a beer with you. He wants to know how soon you could get there from Nashville to see if he should wait for you or not.

You start thinking about the trip and come up with this:

• You’ve driven to Chattanooga many times and it usually takes you about 90 minutes. However, you see that you’ll be arriving in Chattanooga around rush hour so you tack on 15 minutes for the unknown amount of traffic
• You tack on another 15 minutes to the time in case there’s an accident along the way
• You also tack on another 15 minutes since you’ve never been to this part of Chattanooga

You tell your friend you can be there in about 2.25 hours. “Sounds good” says your friend. You’ve done a good job of padding the time in the areas with potential roadblocks and risky unfamiliar neighborhoods. You arrive 5 minutes early and your friend is pleasantly surprised.

What would happen if you had padded the time for each street along the way?

You’ve driven to Chattanooga many times and it usually takes you about 90 minutes
This time you add 15 minutes in case there is traffic on Broadway
Then you add 15 minutes in case there’s an accident on 4th avenue
Left turn add 15 minutes in case of accident or traffic
Right turn add 15 minutes in case of accident or traffic
Continue padding for every street

You tell your friend that you will be there in 6 hours. Your friend says “Sorry, I’ll be gone by then. Maybe next time”

I’ve seen similar situations with software estimation. Developers are notorious for underestimating. Underestimation creates tension for the team and angry unsatisfied customers because they expected it to cost X and take X days but it took longer and costed more.

When this happens, teams will often be so scared of repeating the misery that they go to the opposite extreme. Padding each User Story ensures that you can definitely get it done in the time allotted. Just like expecting traffic at every turn in a short trip between cities.

However, if you send an estimate to a potential client that says it will take 6 months to build and other development shops are quoting 2-3 months, you will most likely not get the project at all. The potential client will say “Maybe next time”, but not really mean it.

Lessons Learned

1. Pad User Stories which have a high risk of taking longer than expected either because you haven’t built this type of module before or because there are too many unknowns.
2. Don’t pad User Stories that you’ve built many times before or are clear and not risky. That way you can manage customer expectations without scaring them away.

Remember, estimates are never perfect. They are meant to help you plan. In Agile Software Estimation, they are also meant to be flexible. However, your experiences can guide you toward more reliable estimates. If you’d like to learn more about Agile Software Estimation, contact us today.