Story 6: Stress more…or forget about time estimates

Accurate estimates are a well-known problem in the world of IT. We always try to reach a level where all items that were estimated become equal to actual implementation. I know this is upsetting but there is no option to achieve it. Of course, sometimes you will perfectly fit it. Still, it is usually over – not bad for your business, but customers might spot that this project is a bit expensive – or under – bad for your business – estimated.

Based on my experience, it is usually the latter. It doesn’t matter if you’re a super experienced programmer or just starting out. I remember things that should have taken 2 weeks and ended up taking six months. Life.

These experiences have shown me more than once that relying on time estimates does not make any sense. It leads to different, potential issues. First of all, we unconsciously put pressure on ourselves – yes, as long as we are humans, we will be used to stress when we run out of time. Therefore, when we estimate that a task will take us approximately 8 hours but in fact, it has already taken 7 and we are not even in the middle of it, we start to hurry – even if nobody rushes us.

Let me ask a question here – do you feel comfortable and can deeply focus on your task when you know that you will not be able to finish it on time? Or when you know that time ran out? I do not.

Another thing to point out is that usually, our customers would like to know the real cost of a feature upfront. What is usually the easiest (in fact, it is not) way to calculate such cost?

• Take a development team
• Ask for an hour/day-based estimate for a feature
• Get an answer, e.g. 78 hours
• Add some risk and other costs, let’s say 1/4, so 20 hours
• You get 98 hours. Now calculate it with your rate, e.g. 100$. This gives you 9800$

You do the offering and the customer is happy. Feature implementation started, and there were several problems. The team gets closer and closer to a total of 78 hours. You are in the middle of development. Next issues come in, the team gets stressed and you are already at 98 hours (total budget of a feature). Finally, development is finished. It took 110 hours.

What might happen next?

Suddenly you realize that the feature earned -12 hours. There are 2 options. First, you can take the next feature (if your customer ordered it) and pray that it will take fewer hours than planned and cover the costs of the previous one.

Another option is to go directly to a customer and tell him – “You know, it took a bit longer than estimated – can you pay more, please?”. If this happens once or twice, it is all fine – probably they will understand. But what if it occurs in all features?

As you might have already seen, time-based estimates are a bit problematic. One solution is to handle estimates that are based on the complexity of a feature and determine its size. With size, you immediately take the time pressure off your team – it is highly possible that their productivity will increase immediately. To define a size, the team can use any unit of measure (other than time 😊). Iteration by iteration, the entire team will get used to thinking in a new way. Furthermore, if your customer is fine with getting size-based estimates, you are a very lucky guy – from this moment time estimates are completely dropped from your project.

Ok. The team measured the size of the first feature. It is LARGE. What does it mean? How can I sell it to my customer? They still ask for the cost. How to calculate it?

“Something is wrong. We still go with estimations using hours.“

How to solve it? I would like to present you with a method that I personally use to migrate from hour to size and complexity-based estimates.

I invite all team members for an analysis meeting to get the estimate of all ordered features. Now I need to prepare for it. How to accomplish it step by step?

I really enjoy t-shirt sizes, so I select it as my choice. There are only 4 sizes that I select to omit the complexity of first estimations. Of course, you can take more if all team members feel comfortable with it – XS, XXL, etc. So chosen sizes are: S (small), M (medium), L (large), and XL (extra-large).

At that point, we do not know what it means that something is small, medium, large, or extra-large. Here you need an assumption. How to make it? Well, it all depends:

1. New team and new project – this is the most difficult situation. You cannot look back as there is nothing. You are on a green field. First of all, you need to take all features, divide and analyze them. Step by step, based on analysis, the team can determine which items are small and which are large in their opinion. When you already have a division into 2 groups it is much easier to divide it into medium and extra-large features.
2. New team and existing project – rare case but difficult as well. Even if you are in the middle of your project and many features have already been completed, the problem is that it was done by completely other guys. That is why you should not directly base on it a size definition. Of course, you might use parts of it as a reference but more as advice. The rest goes the same way as in point 1.
3. Existing team and new project – based on the outcome from the previous project, you can determine which features were in the opinion of a team small, medium, large or extra-large from the perspective of size and complexity. Then, based on project comparison you can set the sizes of new features.
4. Existing team and existing project – You have to sit together, take several completed features, and determine which of these were in the opinion of a team S, M, L, or XL.

While defining the size of a feature, you need to take into consideration that something can be large from the amount of code that needs to be written but small from a complexity perspective or vice versa. You should always take care of both – size and complexity – during estimation.

Remember that even if you defined sizes without any problems, it is just an assumption. You can be sure that it will be adjusted within time.

We are at the moment where there are sizes, so it would be useful to define as well the risk of each estimate. Here I usually go with 2 different levels – low and high. There is nothing in between as it is often liked to get the safe point in the middle. This action can be also handled during the estimation of features, not after – your choice.

You isolated the entire development team from the hour-based estimations. It looks like a list with completed estimates is ready to be delivered to a customer. The problem is that not all customers can relate to size estimations – there are such (you are lucky!) but I would like to focus on those who do not want it.

It is time to make another assumption – you need to define the translation of sizes to hours. You should not show it to anyone involved in the implementation, otherwise, there is a high risk to return to the time pressure. The initial hours that I take into consideration are based on the Fibonacci sequence. This way you do not focus on decisions between 12 and 13 hours as the closest to 13 is 21 (13 + 8). Let’s assume that you selected the following values:

Size	From (hours)	To (hours)
S	1	13
M	21	34
L	55	89
XL	89	144

As you can see, there are several ranges. Why a range and not a concrete value? With range, you are safer. It is better to inform a customer upfront that feature A will take between 1 and 13 hours because then he is prepared for it – no surprises in the end if we promised 7 hours and it took 12. Another thing that is worth mentioning is that there is no overlap between sizes – the next size translation starts with the highest value of the previous size plus the previous value of the Fibonacci sequence.

We are almost there. But why did we define risks and not use them? If there is a low risk, everything stays as it was defined. However, the high-risk changes the range that was defined above. In such a case it is safe to move all estimations +1 size:

Size	From (hours)	To (hours)
S	21	34
M	55	89
L	89	144
XL	144	233

Now you are ready to give a forecast of costs in form of ranges to a customer.

Iteration by iteration, feature by feature you will be able to validate team assumptions and adjust them to your needs. A good idea is to validate your sizes from time to time – if you do it after every iteration, then your results might not be accurate because of random incidents that occurred. At some point, you will come up against a brick wall. Further optimizations will be pointless – the amount of time needed to spend on it will not bring you real value – you can think about it as a funnel. In the beginning, you optimize a lot. Then the scope gets smaller and smaller. Finally, you reach the bottom, where the next optimizations bring more cost than it is worth:

What about you? Do you prefer time or size-based estimates?