I read a blog entry about fibonacci estimation method.
https://dev.to/kakisoft/fibonacci-estimation-method-to-minimize-the-harmful-effects-of-death-march-of-engineers-4a0e
I was amazed so much that I needed to try it right away.
I haven't started development step yet, so this time I applied it only to the estimation step.
I could notice the method works very well from this first try.
To explain it very roughly, here is the following steps.
Divide the function you want to implement into small unit as much as possible than issue task ticket.
You put a point on tickets.
Using the sequence of 2, 3, 5, 8, 13, and 21.
Put a higher point on a heavier ticket.
(It is just a point and there is no unit)
For more information, please refer to the link.
If you apply it properly, you also have to use in development step.
And since this is the first time I'm using it, I don't have any accumulated data from the past.
In this case, I added a 34 point.
The impression I've got after trying it.
I adapted into my project, and I wrote the good point I felt.
And I recommend you to read the blog I refer at first, you can get better idea easily.
Easy to estimate heavy tasks.
The following is a summary and exception.
There is a reason why fibonacci sequence is used instead of consecutive number such as 1, 2, 3, ... 8, 9, 10, when you apply points.
In actual job, weight of task increase exponentially.
There is not much difference in lightweight tasks but heavy tasks have a huge difference.
To make the project members aware of the difference by expanding the gap as it gets heavier.In the case of lighter task, there is a few effect if error occurs, because the different from 2 and 3 point is small.
Estimating is more important for heavier task.Even if you consider carefully as "should we apply 9 for this tasks or 10? ", the difference is only 1 point, and it makes difficult to be aware of the difference between 9 and 10.
So, by using fibonacci the difference between 13 and 21 is huge,
and you can distinguish more clearly such as "if this task is 21 points, then that task is 13 points"
It opens my eyes
Especially, it is very difficult to estimate the implementation of a function with many unknown parts.
No matter how much I think about it, you can't come up with an answer.
However, if you use this method, you can easy to apply the point heavy tasks because next number is clarified.
For example, "OMG! This is difficult! It point is 21. No no no.. there is still the problem of XX ... Then the next point of 34."
You don't have to worry about apply these point, such as "21 points is too low. Then 25 points? 26 points ...? "
Able to concentrate on estimate the tasks.
you don't have to consider the ability of each person
Such as,
"This task needs 3 days. No no no... can he do it in 3 days....?"
"If I do it, I can finish in 2 days, but if I give it to coworker A, it will take 4 days."
"I wish this task be finalize in 1 day. however I'm planning to give this task to newface B.
So, I can assume he needs 3 days. No no no... 2 days."
When we estimate man-hour, we tend to focus on each individual skills.
But, If you use these point without unit, you can concentrate to calculate these tasks volume.
Easy to apply
Some project member tend to be afraid of new method or new change of development process.
They don't want to step out from theirs comfort zone, such as they don't want to change their familiar method or learn new tools.
If you to persuade them, you have to show them demo, create materials, setup the environment to use tools, and research.
These tasks are backbreaking work
While you maintain this formula "curiosity > effort", it's good, but when you're busy with your work, or your co-workers say something hurtful to you and you lose your motivation,
It gets difficult for you to maintain.
On the other hand, fibonacci estimation method is really easy to apply.
The blog that I introduced in the beginning explains everything. So project members would understand the effect of this method once they read it.
Also, Many engineers haven't established estimation method.
There is an opinion says estimation is almost same as horoscope.
In reality, many engineers require to estimate man-hour every single time without enough confidence to their estimation’s reasoning
It means, It is necessary for most of engineers estimation’s reasoning, and they are worried about what is the best way.
When it comes to project team or a company, there is a high possibility they accept your proposal.
In addition, some engineers believes "This computer language is the best!" or "This framework is most polished!".
But no one really cares about estimation method.
From this aspect, It can be assumed your proposal might be accepted.
All of this was my opinion.
When I tried it, I could estimate suitable point and volume.
But I have to create document of man-hour estimation ultimately.
Then I measured point of effort just for try.
To be specific, I finished 5 point task, then I verify the task's man-hour.
So, I found 5 point task is equal to 1 man-hour in this project.
Then I multiply the coefficient to all of the point.
And the result is final estimation number.
As a result I think the number was correct.
I feel if I estimate man-hour ordinary, the result would be pretty close.
If the number is completely wrong, it might be only coefficient problem and the method itself is not wrong.
This method is a lot easier than ordinary one.
If you have difficulties to estimate man-hour, why don't you try it?
I want this method go viral.
I hope that it accumulate success and failure case, and knowledge from practical use on the internet.
I want to contribute it, so I wrote this.
Top comments (0)