Art of Estimating

One of the most difficult and sometimes overlooked aspects of a developer’s job is to be able to accurately predict how long it will take to develop a piece of functionality. This process of estimation is crucial for any company, Salesforce related or not. After all, time is money. The challenge is that estimation is anything but an exact science. This typically causes problems for developers as we are generally from an engineering type of background. Technology is a relatively black and white type of environment. A computer will only do exactly what you tell it to do.

Cone of Uncertainty

One mechanism for making the estimation process more exact is to understand the Cone of Uncertainty. The general idea of the Cone of Uncertainty is that at any given point of the estimation process, the number derived during that process may be up to a factor of X away from the true number. At the beginning of a project, the Cone of Uncertainty states that a best case scenario is to be around a factor of 4 away. This means, if you estimate a task out to be about 10 hours, your best bet is to provide an estimate from 2.5 hours up to 40 hours. Now, I know this is a huge range, but that is the point! At this stage of the project, this is as accurate as you can be with the information you have. The goal is to shrink the cone to a usable level. In my experience, you really need to create a functional specification and a user interface guide to be able to provide an estimate that is a factor of .25 away.

Story Points vs Actual

Agile development is typically estimated against story points. The idea behind story points is that they are an arbitrary measurement that your team can use to estimate difficulty. They don’t necessarily relate 1 to 1 with actual time frames. Someone (typically a project manager) will then use your story point estimates to calculate velocity. Velocity is the calculation of how many story points were completed against a certain time frame. That story point amount is then used to plan out your development effort.

One question you might have is, “doesn’t the velocity essentially tell you exactly how many hours each story point is worth?” Well, yes. The idea though is that it takes the developer out of the thought of “how many hours will this take?” and puts them into the thought of “how difficult is this task?” They essentially ask for the same information, but it takes the specificity out of equation. It then allows your velocity to change with each sprint.

So why would you ever estimate to exact hours/days? Well, story points only make sense in an agile project. If your project has a fixed timeline and scope, agile is not the correct methodology to use. You would be much better served implementing the waterfall model. While the waterfall model is often considered outdated, it still has its place. Specifically in consulting, not every client will want to have an open budget. They will require commitments by your team and the only way to do that is to completely fix the scope. By using the waterfall methodology, it removes any flexibility to make modifications to scope so be aware of that when you implement it or prepare for massive overruns.

Estimation Approaches

There are a multitude of ways to approach an estimate. There are studies, books, lectures, and more on each of them so I won’t go into fine grain detail on any specific methodology. I will however say that I have found planning poker to be relatively accurate. The main thing I like about planning poker is that it isn’t single threaded. By that, I mean that it isn’t up to one person to come up with an estimate. It also allows the people who are actually going to do the work to provide some numbers as well. This provides a level of accountability and buy in from the team that in my opinion is invaluable. It also accounts for the mean of your development team rather than base if off the development skill of just the estimator.

Dealing with Pushback

One uncomfortable experience in the estimation process is when you receive pushback from the product owner, account owner, your manager, etc. There are two extremely important facts to understand in this phase. One is that this is not a personal attack on you. You have to remember, typically it is their job to keep a project to as little time as possible. Time is money and they want to save as much of it as possible. It is actually a good thing that they pushback. It ensures your company keeps making money and allows you to retain your job!

The second, and in my mind, even more important thing to remember is that you are a professional. Early in my career, I was given Clean Code: A Handbook of Agile Software Craftsmanship to read. It changed my career. A few years later, I read The Clean Coder: A Code of Conduct for Professional Programmers within the first two days of it being released. In the book, Robert C. Martin talks about the idea of being professional. As a professional, you have to understand that the number you originally gave was as accurate as you can be. Don’t let someone pressure you into changing that number simply because they don’t agree with it or they don’t think it will sell. All you need to do is say how long it will take. Stick to your guns, stay professional, stay polite, but be firm and resolute. Be confident, justify your estimate, and then leave it be. Don’t debate it, just state it as a fact and leave the situation alone. The person might become upset with you, but there is nothing you can do about that.

Final Thoughts

During the estimation process, make sure you continually communicate at what stage of the cone of estimation you are currently at. Make sure anyone who receives your numbers understand what you felt your were estimating and what level of accuracy you believe those estimates to have. Be a professional and don’t let others sway you. Your opinions are perfectly valid and they are of important value to your team. Good luck!


6 Responses to “Art of Estimating”

  1. February 17, 2014 at 8:29 am #

    Nice article Jesse. Steve McConnell’s book “Software Estimation: Demystifying the Black Art” ( is definitely a great read.

  2. Sean Russell
    February 18, 2014 at 4:38 am #

    These are very good points to keep in mind. Thanks for the article.

  3. March 11, 2014 at 9:36 pm #

    The one link you have to McConnell ( describes the Cloud of Uncertainty as what happens when the project isn’t conducted in a way that reduces variability. I love working on projects in the Cloud…but not that one! 😉

  4. Patrick Herman
    March 12, 2014 at 11:45 am #

    Great article.

Leave a Comment