This is Matsubara from the Coding Factory Department.
Until last year, I worked as a director and coder at Coding Factory (hereafter referred to as CF), but starting this year, I am working as a "project/technical consultation desk", where my main responsibility is calculating the amount of work required to estimate and schedule projects that customers consult me about.
I used to calculate man-hours as part of my job even when I was a coder, but since it became my main job, I've become more conscious than ever of how I can calculate man-hours more efficiently and with greater accuracy.
Meanwhile, I learned that there is a method of estimating man-hours called "Planning Poker" in agile development, and I became very interested in it. I imagined it would be fun because it sounds like a card game, simply because of the name "poker."
After researching it, I quickly realized that unfortunately it wasn't as much of a game as I had thought, and it's not the kind of card game that the whole family can enjoy at the end of the year (it's just a way to spend time).
However, the content was a condensed version of "points to calculating man-hours" that are directly related to the current work. So, this time, based on the basic rules of Planning Poker, I will tell you some points to calculate man-hours that can be used in web production as well.
We have also compiled our impressions of actually playing Planning Poker with the members of CF.
What is Planning Poker?
Planning Poker is a method of estimating the amount of work required by discussing a task with a group of people using cards with numbers written on them. The basic rules are as follows: 1. to 5.
1. Determine the standard work
First, set a base work (A) that is separate from the actual work to be estimated.
The standard task (A) is a task that everyone already knows (has experience with).
Then, decide on the "Story Point" value for that task. Story points are the units used in this game. Let's assume we set the value to "2" and proceed.
2. Determine the work to be estimated and its value
Next, decide what work (B) you will actually estimate.
Furthermore, each participant decides on the value (man-hours) of (B). The way to calculate the man-hours is to use the work volume of (A) as the standard, which is "2," and consider the relative volume of the work of (B). For example, if you think that the work of (B) is about 1.5 times the work of A, then the work of B will be "3" story points.
3. Put a card on the table
Everyone plays the card of the value decided in step 2 at the same time.
Furthermore, each player's cards are prepared in the Fibonacci sequence: "1," "2," "3," "5," "8," "13," and so on.
* In mathematics, a sequence in which the first two terms are 1 and all terms from the third term onwards are the sum of the two terms immediately preceding them
4. Check the reason for the quote
If the number of cards played by all players is the same, that effort will be used.
If the numbers of cards are different, check each one in turn to see why they have that value.
5. Reselect your card
Taking that into consideration, you should choose another card and put it into play.
Repeat steps 4 and 5 until you have all the cards, but if you still don't have all the cards the third time, reconsider whether B is even worth estimating in the first place.
I've roughly explained the overall flow, but there are three important points in this rule.
Point 1
Relative Estimation Method
The first point is to compare work A with work B and make a "relative estimate" of the labor hours.
When judging something, many people find it easier to estimate it relatively by comparing it to something else. Rather than trying to explain it in words, the following image will make this clear at a glance.
If you were to ask "How tall is the Skytree?", you might not be able to come up with a clear answer if you just think about the Skytree alone. However, by comparing it with the Tokyo Tower next to it, you can arrive at the answer that it is "about twice as tall as the Tokyo Tower."
Point 2
Using imaginary units
The second point is that we use a fictional unit called "story points."
In fact, how long it takes to do task (B) depends on the strengths and weaknesses of the person doing the work and their level of experience.
However, when calculating labor hours, you should think not about who will do the work, but about how long the work will take.
By using story points and estimating relatively, everyone can discuss the project using the same idea of "how many times the base value" without being bound by individual skills.
Also, if you make an estimate based on specific hours or days, if the members who will actually be working on the task change from what was planned, you may need to revise your estimate of the amount of work required.
Even in such cases, by combining story points and relative estimation, you can flexibly respond by replacing the effort of the base work.
Point 3
Use the Fibonacci sequence
And the third point is the Fibonacci sequence.
There are various theories about the sequence, so if you want to know more, please see Wikipedia .
The Fibonacci sequence is said to be a good number to use for making estimates.
As the Fibonacci sequence gets larger, the interval between the numbers before and after it gets wider, and this tendency is also seen in actual work, and the larger the scale of the production, the larger the fluctuation in the amount of work required. This is another reason why this sequence is suitable for estimating.
By the way, using the Fibonacci sequence is more of a convention than a rule, and teams are free to decide which numbers to use and what the maximum value should be.
I actually tried it
I still don't have a concrete idea of how Planning Poker can be used in the field, but I thought I'd give it a try! So, with the help of CF members Kanno and Kane, I tried to calculate man-hours using Planning Poker.
As an exercise this time, I decided to estimate the amount of work required to implement JS that "displays the current location using the Google Maps API."
The benchmark task (A) was to implement "tab switching JS" and its value was set to "5" story points.
First, we will estimate the labor hours of the task of (B) “Displaying current location using Google Maps API” relatively compared to the task of (A) “Tab switching JS” individually.
Ready, go! The cards that were put on the table were surprisingly all over the place.
The results were "5," "13," and "20." Not only were they all different, but the differences were huge.
When we asked each person for their reasons, the following opinions were raised:
"I've actually done it before and it was just as good."
(Opinion of the person who gave it a 5)
"It takes time because we have to prepare API keys and set up an SSL environment."
(Opinion of the person who voted 20)
surely.
I thought that the scope of work for (B) might have been a little vague, so I decided to estimate the labor hours for each again, assuming that the API key had already been obtained and the implementation environment was in place, and that the implementation would start from there.
The second time, the cards that came on the table were "3", "8", and "13".
After hearing the reason for the first time, one of the members revised the answer downward, saying, "If that's what someone who has actually tried it says...", but the person who said he had actually tried it came up with a number "3", which was lower than the reference value of (A).
When I asked him why,
"Tab switching can be quite difficult when accessibility is taken into account."
I see.
The standard work (A) was not set properly. For now, let’s not include accessibility.
Hopefully third time's a charm and everyone's numbers will line up!
On the last third turn, the cards that came up were "8", "8", and "13".
What a shame!
So, the numbers didn't match up this time,
As the discussion progressed, we could see that everyone's understanding gradually became aligned and a concrete image of the work was taking shape.
Here's a summary of the thoughts of the members who helped out...
- The rules are simple and anyone can join in right away.
- The card game format makes it easier to express your opinion.
- Relative estimation makes it easier to understand what the other person is thinking.
- Inevitably, the conversation turns to the work process, so just listening is educational.
- For new employees, this will also be an opportunity to learn how to calculate man-hours.
- By taking into account various possibilities, we can arrive at a more accurate estimate.
- It's quite fun.
Even I, the one who brought it up, didn't expect such a positive response!
That being said, it only took about 15 minutes to calculate the man-hours this time. If it takes this long to implement one JS, it would take a lot of time to discuss all the front-end processes, from markup to CMS implementation.
It may be difficult to simply bring the techniques used in agile development into a waterfall-type web production environment, but the ideas of relative estimation, story points, and the Fibonacci sequence can be quickly adopted and I had the feeling that they could be useful when wanting to estimate the effort required for a specific task, such as estimating the effort required for implementing JS in this case.
There seem to be other positive effects that planning poker can bring, so I would like to continue trying it out in the future while thinking about where to use it.
MATSUBARA Megumi