Estimates – migrate your team from time to size based

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

Many projects that I participated in used time based estimates. This approach 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 (it is not) way to calculate such cost?

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

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

What happens then?

You have already spotted that your feature project earned -12 hours. Minus. There are 2 options now – you can take the next feature (if your customer ordered it) and pray that it will take less hours than planned and cover costs of previous, failed one. Or go directly to a customer and tell him face to face – “You know, it took a bit longer than estimated – can you pay more, please?”. If this happens once or twice per project it is all fine – probably they will understand. What if it occurs for 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 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, team can use any unit of measure (other than time 😊). Iteration by iteration, entire team will get used to think 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 retired in your project.

Ok. 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 cost. How to calculate it? I do not like it. We still go with estimations using hours”.

How to solve it? I would like to present you 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?

  1. I really enjoy t-shirt sizes, so I select it as my choice. There are only 4 sizes that I select to omit complexity of first estimations (in my real projects I use 4 as well). Of course you can take more if all team members feel comfortable with it – XS, XXL etc.

      Chosen sizes: S (small), M (medium), L (large), XL (extra-large)

  1. The problem is that I do not know at that point what does it mean 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 it and analyze it. Step by step, based on analysis, 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 to 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 an advice. The rest goes the same way as in point a.

    3. Existing team and new project – based on the outcome from the previous project, you can determine which features were in 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 sizes of new project features.

    4. Existing team and existing project – You have to sit together, take several completed features and determine which of these were in opinion of a team S, M, L or XL.

    5. 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 complexity perspective or vice versa. You should always take care about both – size and complexity – during estimation.

Please remember that even if you defined sizes without any problems, it is just an assumption. For sure it will be adjusted within time.

  1. As we are already at the moment where we have sizes, it would be useful to define as well a risk of each estimate. Here I usually go with 2 different levels – low and high. There is nothing in between as we like to get the safe point in the middle. This action can be also handled during estimation of features (point 2).

      Chosen risk: Low, High

  1. You isolated entire development team from the hour based estimations (none of 3 above points contain any information about time). 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 on size estimations – there are such (you are lucky!) but I would like to focus on our subject of those who do not want it. It is the time to make another assumption – you need to define the translation of sizes to hours. Developers and people who are involved in the implementation should never see it, otherwise they will translate it as well and we will return to the initial state (time pressure!). The initial hours that I take into consideration are based on Fibonacci sequence (this way you do not focus on decision between 12 and 13 hours as the closest to 13 is 21 (13 + 8). Let’s assume that you selected following values:

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

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

  1. Ok – now you can transform sizes directly to hour ranges. We are almost there. But why did we define risks and do not use it? High risk changes ranges that were defined above.



    Low High
    From (hours) To (hours) From (hours) To (hours)
    S 1 13 13 21
    M 21 34 34 55
    L 55 89 89 144
    XL 144 233 233 n

    This method takes the highest value of the selected size and the lowest value of the +1 size, so if we selected S with a high risk, then take 13 hours (the highest value from S) and 21 hours (the lowest value of M):

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

    When there is a situation that team estimated a feature with 2 sizes – L/XL, then you can treat it as an L with a high risk. S/M – M with a high risk etc.

  1. At this point you are able to give a forecast of costs in form of ranges to a customer. Please remember that we only focused on implementation and there are other costs like project management which you need to put upfront.

Iteration by iteration, feature by feature you will be able to validate team assumptions and adjust it to your needs. If you follow Agile and use e.g. SCRUM, then based on several sprint outcomes, a real team velocity can be set as well. A good idea is to validate your sizes each 5 sprints – if you do it after every iteration, then your results might not be accurate because of random incidents that occurred. Some day you will get to a point where further optimizations will be pointless – amount of time needed to spend on it will not bring you a real value – you can think about it as a funnel. At the beginning, we optimize a lot. Then the scope gets smaller and smaller. Finally we are at the bottom, where next optimizations bring more cost than it is worth:

The process overview:

If you are interested in trainings offer related to estimations – from perspective of a developer or a business – you can contact me through the contact form. 🙂

2 thoughts on “Estimates – migrate your team from time to size based

  1. I like most of your idea, basically you defined a feature called SLM. And you did it well! However, to me obscuring size/time transforms deprives the delivery of transparency. I think people need to be empowered to build a trust, they aren’t color-blind, sooner or later they calculate that, and connect the dots. How would you communicate the small refinements/optimizations then? These which take small steps rather than total refitting. Sole, getting back to time pressure seems not justifiable enough to me. I liked your approach towards risk though. Awaiting for the next chapter. Thanks!

    1. Thanks for your comment! 🙂

      You are completely right about communication and trust, especially in the direction of our customers. However, in the context of an implementation team I would still prefer intransparency. The reason of it is that it is a deliberately isolation – you take off the entire pressure, team does not need to even think in the context of time estimations – nobody is interested in time. If this knowledge would be worth to team members, then you should consider spreading this information. Otherwise it is just pointless. 🙂

Zostaw komentarz

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s