This content is a translation of the following website
https://jabba.cloud/20170613054635/?fbclid=IwAR12TiLNPeEHsYaRlbtg98tQ2w9YcpOrR-I5LQprodBiiZUODSwJhGOy13c
I've got permission from the author.
Special thanks for @nodenodenode1 letting me do all this.
cf.
The "I" mentioned in this post is the author of the original article.
I have been swayed by many project managers and their project management methods.
Among them, the method of IT startup in Berlin that I am currently working at is the best.
First, the man-hour estimation is very sophisticated.
What I would like to say is how much that Berlin's company minimizing the harmful effects such as the engineer is forcibly made to say, "I will bring it to an end until this week!" and they are able to keep the promise then the project members were swayed by that.
All project member of the manager's team called this method "fibonacci".
Anyway, I have never met who can estimate accurately.
No one can see the entire complicated project, and guess "It would take **days to finish this with our team".
This estimation will never be correct.
If you ask the engineer heatedly "Hey! you said you could finish the program until this week, didn't you?
Who said that? It was me? Absolutely NO. It was you.
It was from your mouth that I heard all that every single word like 'Until this week'.γIt is Friday night already. What will we do? What will YOU do??? ", that will not make the project go further.
Quite the opposite, if you appreciate to engineer for writing code, that will not work neither.
Unless you have logical basis, you fail to estimate man-hour even if you use a carrot and stick approach.
If I insist that, somebody says "So, Waterfall is bad, now we should adapt Agile."
But all the projects I joined were using Agile.
It goes around a small development process of about two weeks.
Even if you adapt Agile, you need to estimate the man-hours.
There were constant conflicts between the project management team and the development team because of misunderstanding and large estimation errors.
Then, I recommend fibonacci estimation method.
The detail of fibonacci estimation method
As a principle, all project members have to attend the meeting to estimate.
It's a huge waste of time if you linger, so make it as a routine and finish it quickly.
If you repeat it several times, the meeting take 20 to 30 minutes because it is something we do all the time.
[ 1 ] Divide the function you want to implement into small unit as much as possible then issue task ticket.
ex. user registration function by Twitter authentication
[ 2 ] Tag the back-end ,front-end, or etc.
In the case of that it is necessary to implement both Back-end and Front-end, prepare two tickets and tag each one.
ex.)
user registration function by Twitter authentication - back-end
user registration function by Twitter authentication - front-end
[ 3 ] All of the project member put a point for the required man-hours to each ticket using Fibonacci sequence.
Using the sequence of 2, 3, 5, 8, 13, and 21, apply 21 points to the ticket that will take the most man-hours and apply 2 points to the least.
[ 4 ] Sort tickets in order of priority.
Priority based on "which features should be implemented first" apart from the number of points give in step 3.
[ 5 ] Extract only the amount that is likely to be completed within 2 weeks from the top of priority.
It depends on number of team, but normally about 10 to 20 tickets.
[ 6 ] Assign that tickets to each person in charge.
After that, develop and develop.
[ 7 ] Every time bug fixes come out, issue a ticket and put an estimated number of fibonacci to it.
[ 8 ] When the two-week sprint is over, count the total points on the finished ticket.
Don't blame tickets and the person in charge if they haven't finished yet. Just count.
[ 9 ] Return to step 1 and repeat the same procedure.
When the two-week sprint is over, count the total points on the completed ticket again.
If you repeat this many times, the average speed that the team can process in 2 weeks will be calculated in points.
handle
This is well and truly accurate. No matter how much effort you put into developing it, the speed doesn't suddenly double.
Also, the number of points of average speed here is in units of 100 points or something like that, not 100 person-months by any means.
Those points will be the value after the above procedure have been done by all of the project team members.
This can only be described as "The development speed of out team estimated by all of our team members" and in fact, this is surprisingly accurate.
At first I didn't realize how revolutionary idea this was, but there are a few things I've learned after putting it into practice over and over.
Accuracy that can be achieved by not expressing man-hours in days.
You get a false estimate because of some distruction
if you assert some tickets as "the job can be done in 1 day" or "3 days"
The most important point of estimation meeting is accuracy, but you think with ego.
Engineer A : "This is a heavy task, so it will take 4 days."
Engineer B : "What, 4 days? I can do this in one day.
Engineer A : "No, do you take into account that the implementation of this task also includes **? It took more than 4 days when you did a similar job last time."
Engineer B : "What? do you want to fight me?"
project manager : "calm down, Let's say it'll take 1 day, because A and B are both great engineers."
Engineer A. B : "OK."
You can avoid some distruction by using number without an unit for such as 5 or 13.
Since it is just a point and there is no unit, you can only estimate this point by correlation with others.
For example you apply 5 points for the task, so 3 point for the lighter task.
Moreover, No one is assigned to these tasks at this point,
project member no need to make useless appeal such as "I can finish it 1 day"
Clarify difference between heavy tasks by fibonacci
There is a reason why fibonacci sequence is used insted of consecutive number such as 1, 2, 3, ... 8, 9, 10, when you apply points.
First, In actural job, weight of task increase exponentially.
Engineers should realize from thier experience that 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 clealy such as "if this task is 21 points, then that task is 13 points"
Disappear that death march such as "I will bring this task to an end! (But stay up all night)"
Accurate development speed point from full-participation estimating meeting will control messy development plan
If someone tell you to finish varias tasks within 2 weeks,
You can logically persuade "No! Look at the point. It's three times more than the average speed. It's impossible."
You insist "If you really want to integrate that function in current sprint, cut off this task and that task."
And you can collect to realistic plan.
On the contrary, if an engineer says
"There is no way I can finish so many tasks in less than 2 weeks."
then you can also logically persuade
"No, no. look at the point. It's the normal average speed. Why can't you finish it only this time? Don't just say thing without thinking."
The method which consists of logic can firmly excludes people who only speak with their feelings.
In this way, you can get rid of death march such as "I will bring this task to an end! (But stay up all night)".
And you will be able to develop in the healthy environment.
In short, it is very effective that everyone logically understand the development speed of the team.
Don't relate the point completed by individual to personal evaluation.
This is the most important point.
You should all estimate man-hour to drive the project forward, not to evaluate individuals.
If you connect it with a personal evaluation, someone can apply a huge points on a very light task for the sake of earning points,
or there can be a chance of fight for that ticket.
It will just make the situation worse.
This is the outline of fibonacci estimation method.
I've pretended as a wise person to introduce all this, but I'm not particularly specialized in project management methods.
All of this is the secondhand knowledge of my co-worker Spanish project manager R.
He always refers "Agile Estimating and Planning" as his bible and highly recommended book.
In my opinion,
"Aren't you hired so that in-house engineers don't have to read such books?"
Anyway, it seems to be recommended.
Top comments (0)