Currently, new management models such as Scrum, Agile … etc. are increasingly widely applied in software development. The common purpose of these models is to create good products and deliver them to customers on time. However, in the development process, there are many factors that affect the quality of work. One of them is time estimation? Estimate reasonable time, ensuring project progress is always a headache problem for managers.
Here are 4 steps to use for estimating a project
Step 1. Allocate time for estimation If you really want your team to be able to give the best estimate, try not to start the story with something like “I need you to finish all the heads. this is before X ”.
Giving the time to finalize first, then asking the brothers to estimate will make the estimate no longer natural. Consequently, the estimate results will not be close to reality.
When the dev brothers are limited to the deadline and constantly urged to complete the estimation, it will be difficult for people to see the complex elements of the problem to estimate, and will estimate in a manner that tries to please the people. management is key.
Therefore, it is better to allow the whole team a period of time, depending on the size of the project to see the potential complex issues and not to mention the deadline of the features before estimating.
This is so that after the estimate is completed, to decide whether to delete a complicated function too or not.
Step 2. Break the work into sub-tasks Usually at the beginning of the project, you do not have enough detailed information about the features to do. Therefore, the number of days you estimate is often not true to the actual number of days.
However, if you break down the task that needs estimation into smaller jobs, you’ll be able to see in detail the steps needed. Therefore, you will estimate more accurately.
“When you don’t yet know exactly what you will do, you will not know when you will finish it” – Joel Spolsky, Stack Overflow CEO The principle here is that you keep dividing the task until Estimated time to complete each small task is from 8-10h.
Step 3. Task classification After breaking down the task into smaller tasks, you need to step back a bit to see the overall work to be done. You will notice that there are countless things you can begin to do, some of which are still fuzzy, and some of which still contain many mysteries such as the dark side of the moon.
More specifically, we have the following 3 types of jobs:
Known Tasks (Known Tasks)
These are the tasks that you know the input and output and specific steps to take to get the output. Therefore the estimated time to complete this work is determined.
The new task specifies part of what to do (Partially Known Tasks)
This is the type of task that you have only grasped the input, the output and a rough grasp of how to do it. However, you estimate that it will take about 15-30 minutes to learn more or need more help from people who have had similar problems to be able to complete the task.
Unknown task (Unknown Tasks)
Often these tasks will take you a few hours to a day to understand the technology you are going to use to complete the task.
Building software is rarely the construction of things you already know how it works. Usually you will need to find different API tools and platforms to solve problems. Therefore, the time spent studying or researching is an important factor that needs to be taken into account.
After sorting the task, you need to try to set goals to learn more about the project to try to turn the Partially Known Tasks and Unknown Tasks tasks into the Known Tasks type.
Step 4. Estimate again At this point, all your tasks have been converted to the Known Task, you have more specific information for the implementation. Therefore, the resulting estimation results will be more accurate. Take a look at the following chart to see the relationship between the estimation time and the clarity of the requirements as well as the solutions to fulfill the requirements. An advantage of this step is that you have the opportunity to review the requirements, have a more overview. And will be able to spot problems that you haven’t seen before. One point of note here is, every time you have new information about the project, you should estimate again to get the most accurate number.
Note the following 4 while you are estimating the project
Article 1. Note sentences with “Just” – “Just” There is an unwritten rule that often tasks with the “Only” task perform a certain feature:
This task is just as small as a mosquito! It only takes 5 minutes to fix the errors. This task probably doesn’t take more than 15 minutes. These tasks may seem like a waste of time at first, but they often turn out to be the most expensive. These types of tasks are the cause of team delays.
The main reason these types of tasks take more time than expected is that they often appear from daily standup meetings or through conversations between people. When developers do not have enough time to consider the complexity of a task, they will underestimate the complexity and lead to false estimates.
Article 2. Someone who does that person estimates The person assigned to do the task is usually the one who understands or is motivated to best understand the work to be done. This person will be able to see the trivial and equally important details of the job. These are important factors to get the most accurate estimates.
Article 3. Do not ignore odd tasks During project execution, you will receive a lot of small tasks like:
Checkbug Fixbug Review code Build App Deploy App At first glance, these are not very time-consuming. However, there is always something wrong. And you will be hard to predict complexity. Moreover, even if there is no problem, when you add up the time, you get a number that is not small.
Article 4. Considering some possibility of sudden delay A member suddenly becomes ill, or has a vacation, or has a number of mandatory holidays, or a few terrible bugs appear on Unexpected times. You try to rely on your past experience, to consider taking these factors into your estimation results.
Note that during the project, you try to pay attention to unexpected events, the possibility of bugs appearing over time so that you can pay attention to the next estimates.
For estimation, finding accurate results is often difficult. The problem with estimation has nothing to do with estimation. It involves you needing a clear understanding and understanding the exact steps to solve the problems.