Why you should never give off the cuff estimates


This had been one of my longest meetings thus far. You see the team I was in, I was the only developer. The rest of the team was made up of different professionals including designer, UX specialists and animation engineer. Each of us was giving an update on what we were working on. From the buzz of the meeting I heard my name mentioned and the boss asked me “So Chencha how long will it take to enable applicants to use their existing profiles in their applications?”. Without much thought I immediately replied “five days”. The boss typed my response into her mac and moved on. Five days later an email comes in from another team lead asking how do they use the feature that allows applicants to attach existing profiles.

Since then am much wiser and would almost certainly never commit to a schedule just like that. Yet this scenario plays out in software agencies everyday. The client, the manager and sometimes fellow developers expect an immediate answer in days of when something can get completed. Giving an off the cuff answer to this kinds of queries is usually a bad idea.

In this entry, we will explore why this type of estimation is cancer to your project planning.

You will not remember to factor in less visible activities

Asked to give an estimate, most developers will think of the classes, methods, services and other such technical considerations. What will not immediately bubble up will be things like: Time supporting the current version, meetings, organizational commitments, emails etc.

That is, unless you keep a detailed log of all activities, you are highly likely to forget the more mundane ones. The problem is that even mundane activities take time to get done.

It would be wise to keep in mind H.L Mencken quip

    For every complex question. There is an answer that is simple elegant and wrong

With this then it is more important to ensure that the estimate you give is correct rather than it was given quickly.

Commitments are made to others

Unfortunately, many of us in the industry do not differentiate between estimates and commitments. By this I mean that whenever you say “I estimate that this task will take 3 days”, what the client hears is “I commit to getting this done in 3 days”.

In the entry Estimates, Targets and Commitments I delve more into the difference between the terms and how mixing them up comes back to bite you.

For this entry it suffices to say that the estimates you give as a developer feed into the plans of the rest organization. With so much weight, the opinion of how much time a task should take should not be done in a rushed manner.

Devaluation of the proper process

Typically, the estimation process is three step:

  1. Establish the size of the user story relative to other stories
  2. Establish how long it takes to complete one story
  3. Schedule the stories into sprints

Compared to just spitting out the first value that comes to your mind, this process takes a heck more time.

Yet this method still remains one of the most effective ways of arriving at dependable estimates. When you shortcut the process you end up unconsciously training the client to expect immediate estimates. This then ties you into a vicious cycle where your estimates are wrong, so the client asks for another set of estimates, which you then give off the cuff and they end up being wrong and the process repeats ad nauseum.

Accuracy goes off the window

By giving a precise value such as “this will take 3 days” you create the illusion of certainty. In reality, accuracy and precision do not always go together. Eg if I tell you “This will take me a week or so to complete” vs “This will take 5 days to complete”. Which one do you think is more precise? What about more accurate? Obviously the first one is less precise but will likely turn out to be true, the second one is more precise but if anything comes up and I no longer can deliver in five days then the estimate is no longer accurate.

With this in mind, you should then remember that estimates for user stories are given as a triangulation of the estimate given for other similar stories. This eliminates the need to be extremely precise since the estimates are relative.

Traditionally, it has been advised that you give a range such as “This will take 3-5 days to complete”. Personally I doubt the effectiveness of this strategy. Chiefly because being humans, we tend to conveniently forget values we don’t like. So you tell your project manager this will take 3-5 days but what they communicate to the client is that it will take 3 days. That is the range gets collapsed to a single value somewhere in the communication chain.

Do you give off the cuff estimates in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Effective communication within software teams

 photo team-1928848_1280_zpsfklugriw.jpg

Humans are born with the ability and need to communicate. Their vocabulary initially consists of various types of crying: an empty belly, a wet bottom, cold feet, being tired etc. This vocabulary grows with age to include words, expressions and even writing.

By the time our baby is a productive member of a software development team, they probably have a couple of decades of experience in communicating under their belt. Unfortunately, this experience does not always translate to effective communication, especially for software development work.

What works well at the bar and other social situations does not work our as well in the development process.

In this entry, we will be looking at some of the steps you can take to make communication within your teams more effective.

Encourage openness

In government or at least as it is portrayed by Hollywood, they have a term “Need to know”. It describes data that is deemed to be very sensitive. Access to this information is restricted even for those with all necessary security clearance.

Somehow this mentality has seeped into how we do normal business. With the business people sharing only information that they think the developers need to build the product and developers only sharing what they think the client can understand and appreciate.

This insidious practice slowly erodes the trust that the team needs to communicate effectively. After all, how do you know if what you are hearing is all that there is or the other person is withholding something?

It is not enough to ensure that all information is shared, it’s equally important to give everyone a chance to participate in decision-making and the creation of new information. As humans, we naturally own decisions that we feel we had a part in making. This ownership leads to greater contributions of energy to the work being done.

This does not mean that everyone wholly agrees, it is enough that they can live with the decisions made by the group.

Keep the information credible

In the entry Is your backlog still relevant? we mentioned that if you don’t maintain your backlog it will atrophy and eventually be abandoned. This applies to all your other communication tools including documents, spreadsheets and other project management material.

Words are powerful, they give meaning and perspective, yet they only make sense in a context. The words used in your communication materials should be meaningful to all participants. In practice, that means avoid jargon as much as possible.

Eric Evans in his book Domain Driven Design describes ubiquitous language as:

   A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software. 

This simply means that the language that you use should be meaningful within the context of the team.

It may be useful to have a project index describing what the words means especially for highly technical projects.

Keep it fun

By now I have started to gain a reputation as the “processes guy”. I don’t believe this rep adequately represents who I am. Rather, I believe that all we do should have some element of fun in it. If you don’t enjoy the process, no outcome is ever worth it.

This means that while you should respect the formal practices of scrum or whichever project management paradigm that you use, there should also be some room for informal collaboration.

This is what Alistair Cockburn refers to as osmotic communication, the variety of sensory modalities (visual, audio, touch, sense, etc.) that provide a rich set of collaboration clues

Even the ideas that come to the team members when they are not in an official setting should be captured in your project management system. As David Allen usually says:

    The Mind Is For Having Ideas, Not Holding Them

So then let your process allow for anyone who has an idea to express it as quickly as possible without having to wait for the next brainstorming session.

How do you communicate with your own team? Talk to me on the comment section below or on my twitter @jchex