Estimates & different points of view. Business vs developers

No comments

I made an estimate…

I took part in many projects, but there is one I particularly remember…

As soon as I joined the team technical lead gave me a white paper with requirements and asked for estimates of a new functionality. Totally new. I was asked to estimate a chunk of the system (I had no idea how the sytem worked. ups).

I did my best. I knew things may go wrong so I estimated a little more than I thought. But still… I was late.

…and I was late

I did my implementation more or less as estimated. But I haven’t asked about things other than writing code to include in my estimates: meetings, documentation, ingeration with external systems, new corporate process I didn’t yet know existed…

So my overall project work took much more time than I predicted.

It was valuable lesson.

Different points of view

Per dictionary.com:

estimate (noun)
 an approximate judgment or calculation,
 as of the value, amount, time, size, or weight of something

The reason you make estimates is because you don’t know how long something will take.

An estimate is what it is: a guess (not to say a wild guess), an approximate calculation of time needed to deliver a change (I don’t want to say implement, because those two things vary).

If you knew how much time it’ll take, you’d commit to get a change done in a certain time or by a certain date. Because when you commit, you have to get it done in that time or by that date. 

But business views estimates as commitments. So does lots of management folks. And when you miss those estimates they are at least disappointed.

That’s why you still do your best to give an acurrate estimate. But what if you still miss?

How to estimate

There are various techniques of doing estimates: planning poker, wideband delphi, affinity estimation… And probably more…

General idea

All the methods above are a variation of the idea:

team.assemble()
team.discuss(task)
estimates = team.estimate(task)
do{
    team.discuss(estimates)
    estimate = team.reestimate(task)
}while(team.hasAgrredOn(estimate))
  1. The team assembles
  2. The team discusses a task (what the task involves, possible solutions and complications)
  3. Everyone in a team provides estimates
  4. Then iterate until team reaches an agreement:
    1. Discussion of the estimates
    2. Re-estimation

Do it as a team

It’s easier to make an error when you estimate alone then when you estimate in a team. Other people can see things you don’t. They can help you estimate tasks more accurately than when you’d do it by yourself.

Smaller chunks

It’s easier to estimate single step of the functionality flow then the whole feature at once.

Breaking the tasks up is also a good way to understand those tasks better and uncover surprises.

If you break up a one large task into smaller chunks and estimate them separately, the sum of independent estimates will be more accurate than a single estimate of the whole task.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s