How to stop a war with time and start to estimate in the right way.

This article is not about straightforward instructions how the estimation should be. I just want to share my own experience about this topic.

And I would be happy for sure if it helps in your real projects or approaches to reaching the success in the war with time. If you have some adjustments or disagreement — feel free to discuss all the thoughts in the responses in comments.

So let’s come back to the topic. The main purpose of tasks estimation is giving a view at some part of work in some determined time units to (probably, but not only) non-technical people. And you, as an expert in your knowledge area, should care about satisfying several conditions.

The nearest conditions list could look like:

1. Counting all the necessary corners and “bottlenecks” of a given task. A research will be required for them, probably.
2. Looking forward to the scope of the whole tasks. Because we don’t want to make the work double, so we could group the tasks to implement them in more effective way.
3. The depending on someone or something could be an obstacle for working on the task. So you also need to count it in the estimation.
4. Some “risk” coefficient should be defined. It is an individual parameter, but as for me, it’s looking like 20% of possible task estimation time. The main idea of this coefficient is a covering of some accidents and depends on your environment and number of parallel projects you are involved :)

Basically, people are afraid of unknown things and they always will increase the estimation if the task might have some research points. So regarding my own experience, it’s better to not give more than 2 hours for initial research — after it, you will be able to estimate it in a more exact way or fully cancel it because of some impossibility or complicatedness.

A percentage of the overestimate for some risks also could be different. I like next formula which was created in some imperative way through a lot of projects:

percentage risk formula

where:

r — risk coefficient (%, percentage)
P — number of parallel projects you are involved

And let’s make some simple calculations. So you should set 10% percent risk on a task if you are working only for 1 project. But if you will work on 3 projects in parallel then you should set at least 20% — and yeah, that’s my number :)

And I suppose that it’s not a good idea to work on more than 3 projects in parallel. And term “in parallel” means for me switching between projects all the time (so it’s not working on them at the same time). It’s possible because each project has some gaps in it. For example, QA team testing time and waiting for feedback from the customer, etc…

You should always look clearly into the order of the task implementing to avoid unpredictable waiting because of technology inconsistencies.

I hope this rules list can help you to be more productive and will change your way to estimate your work (or work of your department)!

Thank you for reading. Best regards!