[estimate is a rough calculation or guess. estimation is the process of making an estimate]
While every profession is unique in its own way, there is one thing which is common for most of them: providing estimates how long something will take to be done. Essentially, this means you have to provide the time window in which you will execute what you’re paid for. Needless to say, this process is very important, but at the same time, there’s no “official” way to learn it, like you can for instance learn specific programming language. My goal in this article is to highlight why is estimation process is important and suggest some specific techniques how to get better at it.
Before we go into details which explain how the process of estimating may be done, let’s look at why it is so important to begin with. I will introduce you to Parkinson’s law, which explains how we do our work and later on I will elaborate how giving estimations is related to it. After that, I will provide some guidelines how to be better at providing required estimates.
Parkinson's Law
Parkinson’s law says that the amount of work required adjusts to the time available for its completion. This effectively means that if you have three weeks to plan your presentation, it will take you three weeks to do it, even though it may be total of two hours work. While there are many parameters that contribute to this behavior, one of them is procastrination. Knowing that we have enough time to do something, we often tend to leave it for the last moment.
Another example. Imagine you have to plan the tasks for each team member for the next project stage and that this takes three hours to be done. If you have one week for this task, you will probably do this on the last day of a deadline. Or, you may do it before, but you will keep getting back to it and try to perfect it, before sending it to your team. Either way, you will most likelly finish it in a week time.
Yet another example – meetings. If a meeting is scheduled to last one hour and you finish everything in say 42 minutes, the meeting will nonetheless drag for 18 min more, simply to fill in the planned time and so that we have a feeling that we did a good job. Afterall, how many times have you heard someone finished their meeting earlier than planned?
The more time for the task completion we have, the more we’re going to drag it, until finally completing it.
Being aware of Parkinson’s law may help us plan our work, but that is not the topic of this blog post. This brings us to giving estimation.
Why is providing estimation important
Providing task or project estimate is our prediction how long it will take to complete it. Having in mind Parkinson’s law mentioned above, without estimates, we would simply drag on our tasks for much longer than is realistically needed to complete them. On top of that, without estimate, project cannot be planned. By definition, project is individual or collective process determined by it’s beginning and the end. That means we have to plan and estimate all tasks in advance, in order to be able to define the project end.
Last, but certainly not the least, proper estimates are required for a healthy and productive company. They allow us to coordinate teams, plan the budget and ensure that required resources are assigned to whoever needs them.
What is needed for proper estimation process
If you are an individual which is asked to provide an estimate for the current task, you will need to carefully assess all the requirements and indentify what resources you are going to need to complete it. I suggest the follwing set of check points:
- Do you have all the documentation required for the task? If no, seek to obtain everything you need in order to understand the full scope of the task, so you can better calculate the time you need for its execution.
- Have all the requirements been clearly identified? If no, ask your stakeholders to have a discussion about this. You cannot provide proper estimate for the requirement which is not fully defined.
- If you depend on other people for your task, identify them and collect relevant information from them.
- How long did the similar tasks take to complete? Ask you team or manager to get more info. Having the understanding how long it typically took to finish tasks in the similar environment, will provide additional info for you, which will allow you to plan better.
- What are the expected problems in this kind of task, if such can be identified? For example, are the resources you will need easily accessible, or it takes long time to obtain them? In few cases, it took me 2-3 days to obtain one single piece of information from the client, since no one was sure what is the asnwer, and question kept bouncing around. Who would’ve think to take that into account when providing estimate?
- Break main task into smaller ones. Then analyze those and provide estimate for each. It is easier to estimate smaller tasks, than large ones. This method is also called bottom-up estimation.
- Plan for the unknown – good luck with this one! 🙂 On a serious note, unknown things will always happen over the course of project or task. It is not easy to take this into account, but allow some margin in your planning.
- Once you finish your estimation, consult your mentor, team leader or someone you feel comfortable with, and ask for an opinion.
As you get more experience, you will become better in assessing the above matters, which will allow you to improve estimation skills.
If you are a manager of the project and you are asked to provide a project estimate, consider the guidelines mentioned below:
- Identify the expertise and skill set of your team. This will allow you to be aware of what tasks may prove more challenging and where to focus your attention. For example, maybe it turns out you don’t have the required knowledge in the team to complete certain requirements. In this case, you need to ask for more resources for your team.
- Talk about estimation process with your team members. Involving them in the discussion will not only be more productive, but will also enforce team spirit along the way. Discussing all the tasks together as a team, will surely provide you with useful insights.
- Dedicate time in understanding what are the typical problems that may occur along the way. This is easier said than done, but if you bring up this topic with the client, team members or your mentors, it will help you get the better picture. For example, maybe certain set of requirements have very poor documentation related to it, in which case it is advisable to add en extra time needed to implement them.
- Analyze the history of your team: how long it usually took them to complete various tasks, what challenges they faced, what was the hardest for them, what was the easiest. This data will allow you to better map all the tasks that need to be done during the project.
- Ask the right questions in order to help the client differentiates what they need, from what they think they need: how will they measure project success, what is the main goal of the project, who is involved, etc.
- Break project into phases and then analyze each phase separatelly. Planning for the smaller time windows is easier. Consider work breakdown structure approach.
- Add in some time for the unplanned: sick leaves, meetings, problem solving, etc.
The above mentioned questions should make the estimation process easier for you and your team.
How to estimate
There is no magic formula which will allow you to always provide good estimate, however, there are some techniques which make this process easier. One of my favorite approaches is explained by Andy Hunt and Dave Thomas in their great book Pragmatic Programmer.
Authors start with a nice example.
“How long will it take to paint the house?”
“Well, if everything goes right, and this paint has the coverage they claim, it might be as few as 10 hours. But that’s unlikely: I’d guess a more realistic figure is closer to 18 hours. And, of course, if the weather turns bad, that could push it out to 30 hours or more.”
That is how in people in real life give estimation, not with a single number as we usually do – “This task will be done in 5 working days.”
This style of estimating is called PERT – Program Evaluation Review Technique. Every PERT, authors explain, has an optimistic, a most likely and a pessimistic estimate.
So, imagine you are presented with the task of implementing a I2C UVC (talking to you, verification engineers). Your estimation analysis could go something like this:
- Without any problems, when I take into account of learning an I2C protocol, I can do it in 5 working days. That’s optimistic estimate.
- It will probably be a challenge to implement those pull-up resistors logic in bfm and monitor. Also I have one weekly meeting with my TL and meeting with the whole team, which will together take around 2.5 hours. I should be able to deliver in 8 working days. That’s a most likely scenario.
- Worst case scenario, in which I face issues with problem solving, missing licences and poor documentation, means it will probably take me 10 working days.
Now when you put things this way, you can then discuss it with your team leader. They will be able to even prevent some of the issues (e.g. making sure you have the right documentation) and give additional advices how to counter each potential problem you listed. You should also present this to a team member who worked on similar tasks with similar tools, and they should be able to shed some light as well.
I really like PERT approach, as it allows me to analyze the task I have in more detail and be aware of various outcomes. Of course, it is not possible to schedule for everything that can go wrong (slow internet, server is down, wrong script is checked in and you cannot run tests, designer you need got sick and you will get reply tomorrow instead in 5 min, etc), but it’s still better than a single number.
This technique had its cons and those are that you may end up “overplanning”, meaning you spend way too much time analyzing every possible scenario, instead of just getting to the task. As always, key is to find the right balance.
Conclusion
Authors start with a nice example.
“How long will it take to paint the house?”
“Well, if everything goes right, and this paint has the coverage they claim, it might be as few as 10 hours. But that’s unlikely: I’d guess a more realistic figure is closer to 18 hours. And, of course, if the weather turns bad, that could push it out to 30 hours or more.”
That is how in people in real life give estimation, not with a single number as we usually do – “This task will be done in 5 working days.”
This style of estimating is called PERT – Program Evaluation Review Technique. Every PERT, authors explain, has an optimistic, a most likely and a pessimistic estimate.
So, imagine you are presented with the task of implementing a I2C UVC (talking to you, verification engineers). Your estimation analysis could go something like this:
- Without any problems, when I take into account of learning an I2C protocol, I can do it in 5 working days. That’s optimistic estimate.
- It will probably be a challenge to implement those pull-up resistors logic in bfm and monitor. Also I have one weekly meeting with my TL and meeting with the whole team, which will together take around 2.5 hours. I should be able to deliver in 8 working days. That’s a most likely scenario.
- Worst case scenario, in which I face issues with problem solving, missing licences and poor documentation, means it will probably take me 10 working days.
Now when you put things this way, you can then discuss it with your team leader. They will be able to even prevent some of the issues (e.g. making sure you have the right documentation) and give additional advices how to counter each potential problem you listed. You should also present this to a team member who worked on similar tasks with similar tools, and they should be able to shed some light as well.
I really like PERT approach, as it allows me to analyze the task I have in more detail and be aware of various outcomes. Of course, it is not possible to schedule for everything that can go wrong (slow internet, server is down, wrong script is checked in and you cannot run tests, designer you need got sick and you will get reply tomorrow instead in 5 min, etc), but it’s still better than a single number.
This technique had its cons and those are that you may end up “overplanning”, meaning you spend way too much time analyzing every possible scenario, instead of just getting to the task. As always, key is to find the right balance.
