Guide to Time Estimation: Project Estimation Techniques, Tips & Tricks

I’d like to start my guide to successful time estimation with a bit of a joke. Imagine a situation where you think that you’ll finish a certain task in a given amount of time (let’s say 10-20 hours) and you’re not sure in your estimation. In this case, you probably think of a random number and multiply it by the time you predicted, because that number will surely give you enough time to finish the task. Does this technique sound familiar to you? The numbers can vary, of course, but in real life, even if you multiply by 10 or 100, chances are that you'll still miss all deadlines. Just because it’s a guess and not your conscious decision.

Why Some of Us Are So Bad at Time Estimation 

Some people are experts at estimating the amount of time it’ll take to solve a particular problem, while others are just plain terrible at this. This is not just а coincidence. I’m obviously not a psychologist (I am a developer, as you know), but I can give you some thoughts on why some of us are better at time estimation than others.

All people could be divided into groups by some special characteristics based on the way they think, feel, how they make decisions and many other factors. There is a special type indicator, called Myers–Briggs Type Indicator. It includes 4 differentiations, and I’m 100% sure you all have heard of one of them: introverts and extroverts. But I'd like to point out the other type of this indicator: one that describes the way we think and how we prefer to take in information.

According to this indicator, there are two types of people:

• Sensing type. People of this type usually think of things how they really are. He (or she) usually focuses on facts & details and prefers ideas that have practical application or implementation. Usually this kind of person describes things in a direct, literal way. This person thinks in categories that he (or she) can see, or hear, or touch, for example: color, sound and shape.
• Intuitive type. As opposite to sensing type, this type of person tends to think of the future. He (or she) usually sees the big picture and the interconnection of things. These people are interested in ideas and concepts even if they’re totally unrealistic and they describe things in an abstract, poetic way: in terms of time and ideas rather than actual facts.

Not a clue of what these two mean? Ok, let me give you characteristic examples of two jobs that fit the descriptions. Just look at the picture below:

Generally, developers are skilled at doing very logical and applicable things during coding. They actually do implementations of features - that is, it’s part of their job, and that’s almost a literal description of the sensing type of individual. Designers, on the contrary, visualize how things should be and usually don’t just do implementations of their designs. Their job is to provide ideas.

Not all programmers are bad at time estimation, of course, and not all designers are good at it. There is not one person in the world that has the characteristics of only his or her particular type, but in general developers mostly learn to think in a sensory way, not intuitive. And of course it doesn’t mean that you as a developer can’t learn how to do the opposite.

Why Is Time Estimation So Important?

The reason is simple: time is money. We, developers, are paid not for lines of code or stars on GitHub; we’re paid for the time we’re spending on projects.

There are other reasons and they are all interconnected:

• You have to sell your time to a client, project manager, product owner or whoever else is responsible for the project. Whether it’s a potential project (you haven’t signed a contract yet, for example) or just a new task from your project, the client wants to know a deadline for that task(s).
• Understanding the amount of work. When you’re working or planning on working on a project, you have to know your list of tasks and the deadline of a project or project’s stage. The more you know, the better developer you are.
• Planning ahead. You have to plan your own or your team’s work. Even if you’re not a project manager or a lead developer, you still do planning every day: what task you’re going to do next, when you’re going to have a stand-up meeting or how long your lunch break is going to take.

Types Of Time Estimation

There are three types of time estimation:

• Preliminary estimation, a high-level estimation. In front-end development, it’s usually an estimation when you don’t have mockups, design prototypes or even a full description of features. This type of estimation doesn’t have to be perfect; sometimes it’s just a range of numbers to give an idea of what kind of numbers you’re going to operate with: hours, days, weeks or even months.
• Accurate estimation, on the contrary, is a low-level estimation, where absolutely everything should be known beforehand. You have all requirements, mockups and designs, you know what framework and tools you’ll be using. So you have to give an exact number.
• Reevaluation of timings. This type of estimation is employed when something has changed (mockups or the task description, for example), and you have to check your estimation numbers on whether they still fit.

Why We Make Mistakes

There are a few objective reasons why we make mistakes in time estimations and skip deadlines:

• People make mistakes. The number one reason in my opinion is because people tend to make mistakes. It may sound obvious, but it’s still true. We are not robots, we can be distracted, tired, sick, not pay enough attention to important details. I believe you can also add a lot to this list.
• Misunderstanding and lack of information. Another top reason is misunderstanding of what should be done. It’s usually because the description of the task is too short and you just can’t get more details when you’re making an estimation.
• Ignoring risks. There is always a risk that you’ll spend more time on the task than you expected. Just try to remember the last time you spent a few hours on a small 15-minute task and you’ll get the idea what could go wrong if the numbers are in thousands of hours.
• New stuff is hard to estimate. We have to admit, it’s hard to estimate new things (research, third-party technology and APIs). And that’s another reason of estimation mistakes.
• People have different expertise & experience. When you’re working in a team, sometimes it’s easy to forget that not all developers have the same skills and experience. Someone could be good and bad at something. For example, you’re a master of CSS animations, and your colleague could be really good at forms validation. Additionally, there is also a difference between a junior and a senior developer.
• Responsibility. The last common reason that is more applicable to less experienced developers. It occurs when a developer doesn't have a full understanding of how important the number he or she gave is, and how that number could influence the project, the company, and eventually his or her  job.

Successful Time Estimation Techniques

So, where do you start and how do you perform time estimation successfully? It’s not as hard as it seems, and I believe that it’s really worth to try and learn more about this. Here’s some advice that I can give on the topic.

1. Track your time

The first step you should take before you even begin the actual process of estimation is to start tracking your time. There are lots of time tracking apps on the market that will help you with planning and tracking your results. I suggest you make the time tracking routine your regular habit. We do time tracking for all our projects (even internal ones). And when I personally do some off-work stuff, I feel uncomfortable if I don’t track time.

We use Jira time tracking plugin at LOVATA, but in my free time, while working on projects, I usually use Toggl application. It’s simple,easy to use and  has a lot of integrations with other services, including Jira. I know that some of my colleagues also use it to track their time more precisely. But of course you are free to choose the tool that fits you best, or even create your own way of tracking time.

2. Make everything clear

Ok, now you’re doing time tracking for all your projects and tasks. So what’s next? I’d like to give you some advice for the process of estimation itself. The first thing you should do when you’re starting to estimate is to make everything clear. 

Don’t be afraid of asking questions. Even if they may sound obvious or stupid to you, and you might think that you already know how something should be done, or you’ve done that hundreds of times. The client may think in a completely different way. Remember, the more questions you’ll ask, the better understanding you’ll get. It becomes really important for high-level estimation.

Try to find all bottlenecks and sharp edges for all tasks. Even a very simple task could possibly become a not so simple one, because you didn’t bother to think of worst case scenarios.

Additionally, sometimes it’s just impossible to give an exact number, so you may give a range of numbers. For example, from best to worst case scenario.

3. Breaking down into small tasks

Sometimes a task could be too big to estimate. Feel free to decompose it until you’ll get the full understanding of each decomposed task. It’s easy to think of a 5-field form with 3 types of fields and simple zero-value validation than an abstract sign-up form, right?

Think about the implementation of the task. Usually your choice of the framework, a library or even a language (TypeScript or JavaScript) could easily influence your numbers.

Тry to use your common sense and don’t decompose everything for your backlog. There is a big difference between tasks for estimation (where you can go as far as you need: you can even do estimation literally for each function or a line of code you’re going to write) and tasks for implementation. For example, if you have a simple social sharing widget to implement, with buttons of different social networks to share content. During estimation, you can divide implementation of each button as a stand-alone task, and estimate them separately. But for your backlog, it’s probably a better idea not to decompose the task because, chances are, developers will spend more time to do some work-around stuff than actual coding.

4. Work as a team

If you’re working in a team, it’s always good to do estimation together. If you’re sharing your experience, it becomes harder to miss something (remember the “people make mistakes” postulate?).

We all know that code reviews are really good to improve your skills. Sometimes the whole team just doesn’t have time to gather and do a full estimation. So it’s a good practice to ask someone else to look at numbers and provide some feedback.

5. Risk prevention

There are always such things as third-party APIs the client wants to use, “unknown” business logic that changes the process of development, or a new tool you’re going to use that may break your deadlines. So identify such tasks as ‘risky’ tasks and be ready to add additional time for their implementation. It’s a good idea to discuss this with your client. Maybe you could modify the task so it will eventually become a “no risky” one. Or even remove it from your task list because the result is not worth the risk.

Each member of your team should know all the risks. By doing so. you’re sharing responsibility, and I believe it’s a good thing. Unless you’re using it to blame someone for skipped deadlines.

Take additional time to do research for tasks. Let’s say you’re estimating a really high-level task, and you haven’t yet decided which framework you’re going to use. Just spend enough time to look at all the opportunities, read documentation, blogs and reviews. After that, make your final decision. Finally, don’t forget about reevaluation after your research, if you already gave numbers.

6. Include other activities besides coding.

Another part of estimation is developer’s risks. Remember that you don’t spend 100% of your time on coding. You usually do a lot of things besides coding: 

• Read documentation and description of the task; 
• Deploy and spend time on code review. 
• You probably do testing, at least in a few modern browsers, if not - unit or other code testing. 
• You have meeting or online calls with the team and/or the client. 
• You probably read some resources to improve your skills in general. 
• And of course you drink coffee/tea, eat cookies, read and send email, have small talks with colleagues during the day. 

All of these are the part of the development process and you should include them in the project estimation.

More Tips & Tricks on Project Estimation and Planning

The next bunch of tips isn't necessarily connected with the process of estimation itself, but it does have ties to development and has influence on project estimation and planning.

1. Regular reevaluation. 

Remember, I’ve told you that reevaluation is an important type of estimation. And I strongly suggest you do it every time you’re going to start a new task. Just because the number you have right now could be outdated, and you will definitely skip a deadline if that’s the case.

2. Discuss exact implementation. 

The second point I would like to make here is how it’s vital to discuss the exact implementation. It’s almost the same as my advice on thinking about implementation during the estimation process, but here it should be an even more detailed discussion, because, probably, you have a lot of things done by this moment. 

A good example here would be a discussion of the implementation of a feature that requires two developers: front-end and back-end. Such discussion will most probably lessen the time they’ll spend on the task.

3. Don’t be afraid to ask for help.

You can’t be an expert in all areas of development. It’s simply impossible, because the development world, and the front-end particularly, is too big to know everything. To be successful, you have to know a lot, but not everything. So don't be afraid of asking for help: whether you don’t know how to implement something, or you have issues with timing. 

David Hansson, creator of Ruby on Rails, Founder & CTO at Basecamp, NYT Best-selling author of REWORK and REMOTE 

As soon as you’ve realized that you won’t fit your deadline, it’s time to tell the news to your team, project manager or even the client. For example, you’re implementing an 8-hour task, and you’re in the middle of the process. So you’ve already spent 4 hours on the task, and just realized that you need 2 extra hours. That’s the right moment to inform everyone responsible for timing on your project and figure out what to do next. Sometimes numbers are not so positive, of course, but in any case you, your team and even your client need to know this. The good thing is that we’re all humans, and even a very harsh client could be persuaded to make changes: choose another user experience flow, simplify the task, remove it from the release or move a deadline.

4. Time estimation is not about prediction.

When you do time estimation, you have to gather all your past experience, and you can’t do that without numbers you tracked during the process of development. Pay more attention to over- and underestimated tasks and try to find out what has gone wrong in each case.

For those who like numbers, I have a special formula that will help you calculate your personal error factor:

It’s that simple. Just divide logged time by estimated time. Ideally you’ll get “1” as a result. In the case when the number is greater than 1, it means that you’ve spent more time than expected, and it’s obviously a bad thing. If your factor is less than 1, it’s usually a bad thing too. Maybe if you’re working for an outsource company, it’s a good thing from the company’s perspective (this way the company makes more money in a shorter period of time), but from the planning perspective, your estimation is still not reliable.

Bonus Tips & Tricks

The final bonus list of tips is not related to estimation or coding, but still has influence on your project deadlines. Even if you’re not a project manager or a lead developer, it would be great to at least know about them.

1. Communication is a virtue.

Hundreds and thousands of deadlines were not met just because team members didn’t have proper communication. It’s not even about work space organization: two developers could sit next to each other in an open space office and not share a word the whole day. I think that communication is one of the most important soft skills for developers.

2. Encourage your team to estimate.

I strongly believe that estimations must be made by developers themselves, or at least every developer has to have a chance to change numbers before implementing the task. So, as a lead developer, you should motivate your team to learn how to do that, even if you’re not good at it. Learn together.

3. Group developers by skill attributes.

If you have an opportunity to move people around the office, try it. Group people by some attribute. Obviously,  I’m not talking about personal attributes, like gender, skin color or whatever. I’m talking about professional skills. For instance, front-end developers are sitting in one space, back-end developers in another, and so on. 

A few years ago we decided to group developers by projects, not by departments. I believe it was a success because we all had an opportunity to gather more experience from different areas of development.

4. Always try something new.

I encourage you to try different development techniques. For example, we found out that pair programming could be very useful in a couple of ways. The first is when a junior and senior developer sit together and share experience in the same area. The second useful way is for different kind of developers: front-end and back-end, to work together. This can prove to be very useful when there’s strong integration between the client and the server. Especially when the front-end developer has no idea what’s going on on the back-end part, while the back-end developer also has no clue on what’s going on in the modern hyped up framework on the front-end.

Conclusion

I hope these tips and tricks from my personal professional experience have given you some valuable insight into time estimation and management. If you’re a beginner in time estimation, it may sound like a difficult thing to master, and you’ll probably spend some time to make the process your everyday routine, but it will totally be worth it in the end. Especially for high-level estimation tasks, when mistakes could cost your company thousands of dollars. Stay tuned for upcoming blog articles on this topic.

About the Author

Aleksandra Shinkevich is a Full Stack (MEAN) developer at LOVATA Software Development Company. As a Lead Developer, she’s involved in the process of estimation and project management. In her free time, she organizes regular local front-end meetups, such as MinskCSS and MinskJS. In September 2017 she was among the organizers of the country’s first English-only front-end conference, CSS-Minsk-JS.