NOT Another Post About Estimation

By | June 22, 2014

I was involved in a project that was given 10 days to finish, the tight schedule was due to budget reasons.

The client explained to me his requirements and then asked for an estimate for details. We stood in front of the whiteboard, broke down the features and then started estimating the time for these features, until we reached feature x.

In my technical life I’ve been beaten by over-simplified requirements far too many times, so as simple as feature x sounded I strongly felt that it might stretch. Subsequently, this influenced my opinion of giving feature x three days, against which the client of course argued back.

Reasonably enough, I listened, and then naturally gave counter arguments, but still the client insisted “this feature will NOT take three days!”. Going back and forth I realized that the gap of understanding the feature between us was too great.
One way this could’ve continued is that I would have sat with him, tried to come up with all the possible scenarios and all the details involved in building feature x… until I convinced him, or of course until he convinced me. Weighing the costs and the benefits of this approach, it was not worth it! we would have wasted probably couple of hours just arguing if the feature is going to take 1 or 3 days; this means that we would have wasted between 17-50% of the feature time arguing how much it’s going to take!

So I chose not to go that direction, instead I questioned the value of estimating in this scenario, do we really need to estimate the details of this feature in a 10 days project? estimates are needed to take decisions now for situations that is going to happen in the future, the decision has to be made RIGHT NOW. So what is the decision we are trying to make here? The client’s answer was “I would build feature x differently”, so it was the “How”; how should we build feature x? should we take shortcuts? should we cut scope?
Of course we need this decision, but do we need it NOW? as we said it is so expensive; we are in dispute and remember it’s 17-50%!

How can we solve this? the answer “I don’t need this decision right now”, and hence I don’t need estimating it! but how did I come to this conclusion? How did I know that I don’t need it? by examining the rest of the features; if all the other features are so basic, of a higher importance, and on which there was no dispute,… then I can push feature x to the end of the project, and only when I start implementing it I would revisit my decision of how to do it. By that I will have had proper picture of how things are going and would be able to decide how to build it without the fear of messing up the whole project, and without delaying it by wasting time in estimating, “it is going to take what it is going to take”.

Let’s take an example.
In every morning I do four things:

1- wash my face
2- iron my shirt
3- pack my laptop
4- pack my lunch

I know exactly how long each of these tasks take, except for number 2; it depends on the fabric of the shirt, the performance of the iron…etc. Now, when I wake up I need to estimate how long these tasks take so I can “decide” whether to call my employer and inform him that I’d be late or not. In order to do that I would sit and think “hmm…how much time would ironing my shirt take me? if my blue shirt is already washed then it would be good because it’s the easiest to be ironed, but then the iron could need water, if I start filling it…” and I would spend god knows how long thinking of how much time ironing my shirt would take.
Instead of doing all that, I prioritize; I push task 2 till the very end and then when I am ACTUALLY DOING the task, things are much more clear and I can DECIDE if I can iron my blue shirt, or take a shortcut by grabbing my white t-shirt, and eventually to call my employer or not.

Maybe the following diagram would make the picture little bit more clear.

Picture3

You can see from diagram 1.0 that having the ambiguous task in the middle puts all the subsequent tasks into risk.

Picture4

Diagram 2.0 shows that pushing the ambiguous task to the end mitigates the risks, and leaves the decision of how to build it just before it starts with much clearer vision.

Conclusion

The highlight here is NOT about estimation, the highlight here is that every project is unique and should be assessed accordingly; before taking any step during the project ask yourself what value does it provide? what cost does it incur? is there other ways by which I can achieve my goal?

Happy delivering πŸ™‚

2 thoughts on “NOT Another Post About Estimation

  1. Brian W

    Emad,
    I agree with not getting “stuck in mud” and losing % on the project. One point, however, it is also important in how this is communicated to the client. If insufficiently communicated it could be “assumed” that by having not putting your case forward strongly == it’ll be done as per the client’s pov (a mistake I have made many a time).
    A lot of the time, the communication is as (if not more so) important than the “code”.
    Happy delivering, indeed ! πŸ™‚

  2. Emad Alashi Post author

    I agree! this should be done collaboratively you AND the client: “I don’t agree with you on the estimate, but what we can do is we can revisit this later and decide then”. I definitely don’t encourage showing an artificial agreement when in fact it is not.

    Good Point Brian πŸ™‚

Leave a Reply

Your email address will not be published. Required fields are marked *