How to Estimate Programming Tasks
In this video you will learn how to estimate your programming features and projects more realistically with advices from my 10 years of programming experience. Also make sure that you watch video until the end because I will tell you how to estimate task really accurately using planning poker. So let's jump right into it.
As a programmer in any company you and your team must deliver results. Either you are planning a feature or a project the first question that you will get from the manager or business is "How long do you need to do this" or "When this project will be ready?".
They worst answer then exists here is "Looks easy. I think 2 weeks are fine". In 2 weeks it will be for sure not ready and business will ask "Why it is not ready yet?". Here we get pressure and overtimes which I can't recommend to anybody. So we must try to estimate features or projects as accurate as possible.
Let's start with the basics. Any task consists of some parts that you know and some parts that you don't know. I you need to create an authentication API but you never did it you estimations will be totally random because you knowledge on the subject is zero. If you watched some videos about the topic and understand at least roughly what it is done that 20-30% of what you know and 70% that you don't. The more you know the better your estimations are.
Important note: If you don't have any knowledge on the subject the best answer is "I need time to investigate the topic. Let's make a 1 day investigation so I can estimate the task better".
If you are estimating something bigger than 1-2 days of implementation it makes sense to split it in several tickets. Because as the amount of days that you need grows you estimations become more inaccurate even for experienced developer.
One more important thing is to do as little work as possible which is often called MVP or minimum valuable product. When business wants a new project or a new feature while discussing try to cut functionality to absolute minimum. If new feature like business wants it sounds like a month of work think how you can make it easier, only with core functionality to make a first release in a week. It will be easier to implement and estimate. Also business will see results much faster and can plan next steps accordingly.
If you implement a feature 1-2 months or longer and then it's not solving a problem or already released too late it's wrong approach for planning in general.
Also most developers have a problem to estimate everything too optimistic. Especially if you have experience features look easy and developers are not thinking about some usecases that might be hard to implement. So take your time and make evaluation. Write steps what you will do. After each planning and implementation check how accurate were your estimations and ask yourself why. It will help you to improve your accuracy.
Also important note: If you think if probably take from 1 to 2 days always take bigger number. Normally everything take more time than planned.
The last thing that you need to know is story points, man days and planning poker. So normally people estimate task in man days (how many days a single person need to do this). This sounds logical and extremely popular because for business a sentence "It will take 2 days" is extremely clear. The other way is to estimate the difficulty of tasks using story points. So we name a feature or task a story and give it points. If it's easy we say it's 1, if medium 3-4 if difficult 5 or 10 depends on the team. Important thing is that you estimate here complexity based on the previous tickets that you already done. Also the problem here for developers and business is that there is no transparent correlation between story points and days. The sense "This task is 3 story points" doesn't make any sense for business.
So here we come to planning poker. History showed us that if we ask 10 people to estimate a task and take the average number it will be quite accurate. This is what is often used to estimate tickets in companies. Several developers sit in a circle and show their estimations at the same time using cards. So 1 person show 1, 2 people 3 and 1 person 5. Normally developers with smallest and biggest numbers should tell why they think it is so difficult or so easy. Then after this additional information we can estimate again and get quite accurate numbers. As we use cards with numbers here it is called planning poker.
So this were the basic of correct estimations. The short way to improve your estimations is estimate -> do -> think why estimations were so optimistic -> estimate again.
Want to conquer your next JavaScript interview? Download my FREE PDF - Pass Your JS Interview with Confidence and start preparing for success today!
