#16 Stress Less: Forget About Time Estimates

Time-related stress can kill the team's productivity and lead to progressive demotivation. What can you do if you cannot skip estimates? Focus on the size and the complexity.

Accurate estimates are a well-known problem. We try to reach a level where all estimates equal actual implementation. What I will say might be demotivating, but there is no way to achieve this. Of course, sometimes you will perfectly fit it. Still, it is usually under- or overestimated.

If you can skip any estimates, do it. You will see how much effort is lost in predicting the unpredictable future.

Relying on time-based estimates does not make much sense. It leads to various issues. First of all, we unconsciously put pressure on ourselves. As long as we are humans, we are used to stress when we run out of time. Therefore, when we estimate that a task will take us approximately 8 hours, but it has already taken 7, and we are not even in the middle of it, we start to hurry.

Even if nobody rushes us.

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 has run out?

Unfortunately, skipping the estimates is often impossible because of the organization’s rules, hierarchy, and other fancy stuff. Don’t worry. I've got you covered with an alternative.

Try to focus on the complexity of the item and determine its size. With size, you immediately take the time pressure off your team, which usually positively impacts productivity.

The team can define size using any unit of measure other than time. My favorite way is to use t-shirt sizes. Why not story points? Too often, they are translated into hours as they are just plain numbers.

To simplify the estimation process and omit analysis paralysis, I base it on four sizes:

• Small (S)

• Medium (M)

• Large (L)

• Extra Large (XL)

Of course, this is only my recommendation - you can go your own way and use as many sizes as possible.

There is one issue - at that point, you do not know what it means that something is small or large. You need to have a reference in the form of previously estimated items or make an assumption. Usually, you will face one of the following scenarios:

1. New team and new project – this is the most challenging situation. You cannot look back because there is nothing. You are working on a greenfield application. First, divide all items that must be estimated into two groups - small and large. At this point, an item can be either simple and small (small), simple and large (large), complex and small (large), or complex and large (large). Next, review your grouping and try to place them across medium and extra-large groups. With time, your references will become more and more accurate.

2. New team and existing project – this is a rare case and means that your team overtook an existing project. There are previous items that were estimated by another team, but you cannot directly reference them - you have different skills and experience, and maybe the environment has changed as well. Therefore, the process of your first estimates will be the same as the one described in the previous point.

3. Existing team and new project – you already worked together on another project. Your experience might help you estimate items for the new project. You can compare new items to the ones from the previous project. IMPORTANT: Sometimes it is a trap, primarily when you worked on a legacy application that required a lot of workarounds - such references won’t be accurate in the greenfield app where you can achieve functionality more easily.

4. Existing team and existing project – the most straightforward case. You already finished some items that can work as a reference while estimating new ones. You sit together and determine the size and the complexity (S, M, L, XL), comparing them to the previous ones. Within each estimation round, they will get more accurate.

While defining an item's size, you need to take into consideration that it might be large due to the amount of code that needs to be written but small from a complexity perspective or vice versa. You should always remember about both size and complexity.

The definition of the size and complexity will change over time. Thanks to that, references will get more and more accurate.

Besides size and complexity, defining each estimate’s risk is also helpful. My recommendation is to start with two levels—low and high. In case of low risk, you do not need to adjust anything. However, if you spot an item with a high risk, it is better to move it +1 (S to M, M to L, L to XL).

Sometimes, you will be told that eliminating time-based estimates is impossible—your project manager or someone else requires them, and there is no way to change that.

In such a case, don’t handle the translation in the development team - if someone needs it, let them do it. They can translate it based on the items already done (real numbers). If you do that within the development team, the time pressure is back, and the size estimates will be heavily affected by time:

It is easy, small is 8 hours, medium is 13 hours! - never, ever do that.

How do you handle estimates within your team?