Foreword

I think one of the hardest parts of programming is an estimation. When I program by the request of a person, the first question that is always asked is "How long will it end?". If you are in a more harsh situation, you will be asked: "What day will you deliver?" (This may be normal). We recall all the experience and estimate the time it may take, or break it down into tasks as much as possible to estimate the time, but we are always worried. Many people seem to have difficulty and anxiety about the estimate. I wrote an article to share my knowledge and experience to help others.

The word "estimate" has various meanings, but in this article, it means "Estimating the time until product release" or "Estimating the time to complete one requested function".

Why should I make an estimate?

There are many reasons why you need to make an estimate.
One is investment judgment. A time estimate is required to calculate how much money it will cost to develop the product or function and to determine whether it worth the cost.
If you know the time in advance, you can use it to know when to start preparing a marketing campaign or to decide if you should drop more people. If you don't know how much time and money it takes, you won't be able to make other plans. Because of these important reasons, we need to estimate our work.

Why is it difficult to estimate

Why is it difficult to estimate? That's because there is too much uncertainty.

Never know how long it will take
Maybe there are unexpected tasks
We don't know how long it will take to learn the framework and technology
There may be pitfalls
I don't know how long it will take to find and fix a bug
With team development, you don't know other people's development speed. I don't know what I am in charge of.

There will be many more reasons. In the first place, it is rare that you first fully understand what you will develop. I don't want to estimate things that I don't understand. But I do because it's necessary.

Other reason which makes it difficult

I talked about the fact that there is a lot of uncertainty that makes it difficult to estimate. But still, we can make realistic assumptions if we try. However, there is one more thing that makes it difficult to estimate.

That is the fact that the estimated date will be the deadline.

If you tell your boss, "I think I will end the task in a week", you will have to work overtime until late at night on Friday. If it is a delivery date, you need to deliver by any means.
Because of this, we can't say easily "I think I will end the task in a week." even if we estimate that it will end in about a week.

We cannot conclude a certain finish time from uncertain circumstances. The estimate is most likely to "it will end in a week, but varies by 50-200%".

I always think that the inconsistency between the actual state of the estimate and the required estimate (deadline) makes it difficult to estimate.

Estimating method

The difficulty of estimation is uncertainty and disagreement, but what is the sincere attitude to face these difficulties?
First, I would like to introduce an estimate based on story points and velocity used in agile development as a method to deal with uncertainty.

Story points and velocity

Story points

Estimating a task with an absolute assessment is difficult due to uncertainty. Therefore, Let's estimate by relative evaluation is the story point.
If work A is 5 points, work B, which is likely to take twice as much as work A, is 10 points. Work C, which does not take as much as work B but is more difficult than work A, is set to 7 points. You estimate tasks like that.
It is said that people can assess accurately by relative assessments rather than absolute assessments. It is difficult to tell how many meters the height of a building that is visible in the distance is, but anyone can accurately estimate how many times it is larger than the small building next to it.
The total points are estimated for the product or function to be completed.

Velocity

The story points alone have no meaning. The reason for making the estimate was to make a decision or use it for another plan, so it must be converted to time.
Velocity is what makes it possible.

Do the task and measure how much time it takes per one story point.
If we estimate the story point of one function development as 80 points and it takes 1 day to complete an 8 point task, we can guess that the function development will be over in 10 days.

Burn Chart

The total story points, completed story points, and remaining story points displayed on a line graph in chronological order are called burn charts.
If the project is progressing smoothly, the remaining story point will be a negative straight line, and the point where the straight line extends and overlaps the x-axis will be the scheduled project completion date.
Visualization is important for checking and sharing progress.

Providing an estimate that incorporates uncertainty

I stated that estimation would be considered as a deadline, which makes it difficult to estimate.
Because of the deadline, we put an excessive buffer for self-defense at the expense of accurate estimates. I think it will end in one week, but I will tell you that it is two weeks just in case. But is this a sincere attitude?
I think that changing the way of communicating is one way.
Rather than telling "I'll finish two weeks later", saying "I estimated that the whole project will take 4-10 days. I expect to have this result in the first 3 days", and sharing the burn chart as a way to check the current progress is more sincere in that it conveys the exact information I have and that it accepts that the estimate is uncertain. And the important thing is that the estimates are always revised. Acknowledging the highest level of uncertainty at the beginning of the project and reducing uncertainty by making a re-estimation in the process of acquiring knowledge. Share estimates that will be accurate with decision-makers.

Re-estimate

If a task that was estimated to take 2 days took 3 days in real progress, the common people tend to think "Why didn't we go with the estimate?" And the next task you will make an effort to keep up with the schedule. My experience shows that the effort to speed up when not on schedule makes the project more worth. The code would be less maintainable. Bugs would be left alone. If you come up with a valuable feature, you will ignore it because of no time.
We don't want to make these "efforts". Then, you should think this way.
"A task that took 3 days was incorrectly estimated as 2 days."
The estimate should be revised. This time, we will re-estimate similar tasks by multiplying the story point 1.5 times. Make corrections to make estimates more accurate.

Finally

This time, we shared a way of thinking about the estimate and introduced a method based on story points used in agile development.
Of course, the environment in which each reader is placed is different, so I think that there are some environments where the methods and ideas described in this article cannot be applied.
I would be grateful if I help you.

See you!