How to Get Your Team to Estimate Better in 3 Simple Steps

Dealing with software development, have you ever faced the situation when your development team under- or overestimates the work?

We are pretty sure that the answer is yes. Any product development process can involve issues at the estimate stage, which can influence the project success.

Many claim incorrect estimates happen due to the developers’ incompetence or lack of experience. But do you think it really depends on their professional skills? We believe it does not. In this article, we will analyze the reasons and share our way to solve this issue.

Estimate as an important project stage

You can hear the word ‘estimate’ almost daily. Why is it that important? The matter is that the accuracy of your time and cost estimation can either wreck or build the project success. There are two possibilities that may lead to negative results.

Underestimation will lead to rescheduling the whole project development, and this may affect the future planned events. Also, it may influence the discussed budget that results in losing the credibility to the custom software development firm.

On the flipside, overestimation results in losing the available time. For example, If you give a development team 20 days to complete a task that could be completed in 14 days, then these 6 days are your loss.

Furthermore, overestimating the tasks may lead to procrastination. It means developers are given too much time, and they will relax until the project deadline approaches. As a result, the team will rush to complete the work, and most likely they will not finish it on time or provide you with a low-quality result.

How to choose the right approach for an estimate? To succeed in it, we should define the existing project types and their differences:

• Projects having an accurate target, technical inquiry and deadlines.
• Projects having a general idea and no accurate visualization of further development, like products for startups or Time & Material projects.

The first project type requires using traditional estimate approach in man-hours. It is the only right option as the customers want to have an accurate estimate. It means they require exact deadlines and a clear budget to know how much money should be spent. That’s why an agile methodology is not a good option here.

When dealing with the second project type, it’s important to understand that most likely there is no clear vision and no final functionality list. The requirements may and will change during the development process, sometimes even daily. So, this is where the agile methodology is best suited for.

You may find interesting: How we implemented Agile at Codica.

No matter what project type you are dealing with, correct estimation is required and important. You always need to be fully aware of the development schedule, accurate delivery speed and, consequently, the budget you are aiming to meet.

What difficulties can you face?

The majority of developers base their estimations on their previous experience or just play a guessing game. The latter approach usually leads to the fatal assumptions on your estimation reports and further project planning.

Our experience shows that the reasons for incorrect estimates are usually the following:

• Developer’s experience gap. In case the developer faces some task for the first time, then it is impossible for them to understand how long it will take to complete this work.
• Incorrect risk assessment. Most estimates are hugely optimistic.
• Project peculiarities. From the project context, a task may seem simple and straightforward, if the developer has already faced a similar one. In reality, the same task in a new project may take much longer.

Here comes an issue of how to estimate tasks dealing with mentioned above projects, and how to get quality feedback from your development team. Codica team has found the answers to these questions.

Want to stay tuned for tips on management from experts?

Subscribe to our monthly newsletter.

The way to quality estimates

All developers should be taught and prepared to properly evaluate their work time. Moreover, they should overcome the psychological barrier that frequently appears while estimating. Only then they will be able to provide you with an accurate estimate.

At Codica, to meet these results and achieve a high-quality estimate, we adopt an effective approach using agile methodologies. It consists of just a few steps absolutely easy to follow.

Begin with T-shirt sizes

T-shirt sizing approach is an effective agile estimation technique to scope a large amount of work as fast as possible without getting into analysis paralysis. We are not sure you came around to try this style of estimation before. From our point of view, it’s the easiest way to estimate.

Tip: It is important to concentrate on the scale of complexity, not the amount of further work.

When estimating the project tasks, you need to focus on the complexity of each task matching it with the T-Shirt sizes: XS, S, M, L, XL.

Sizes ‘XS’ and ‘S’

Obviously, the lightest and easiest tasks go are S- and XS-sized. Such a task can be adding a button on the website or changing its position, updating the pixels, etc.

Size ‘M’

Here is another case: a developer happened to solve a similar task before, but a new one still requires more work to execute? Having sufficient dev’s experience, the best solution is to evaluate it as M-sized.

Size ‘L’

Sometimes, you can face a challenging task which is daunting in development. Consequently, you need time for an investigation. The right solution is to evaluate this task as L-sized.

Size ‘XL’

Obviously, the largest tasks should be evaluated as XL-sized. However, in case you deal with a huge amount of work and complexity within the task, just decompose it into small parts. For example, if your developers have estimated the task for XL, then it is better to break it into several M-sized tasks. This approach allows calculating the hours accurately in the future.

This way developers draw a distinction for each task. By removing the numerical score, the team is free to think in a more abstract way. The creative side of the team can be effective at getting them out of their analytical thought processes and into a more flexible, relative mindset.

While T-shirt sizes can be very effective for teams just starting out with agile, eventually it’s a good idea to move the team toward a more rational numerical scale.

Convert T-shirt sizes into story points

Discovering the agile methodologies and approaches, we cannot but mention story points. This approach is used to estimate the tasks in almost the same way as a T-Shirt approach.

However, in this approach, the T-Shirt method is further converted into a numeral scale and here comes the correlation.

To provide your development team with an easy transition, use the following scheme:

• XS - between 1 and 2 SP;
• S - between 3 and 5 SP;
• M - between 5 and 8 SP;
• L - between 8 and 13 SP;
• XL - between 13 and 21 SP.

This step is highly effective for the developers to complete a transition from T-Shirt sizes to numbers. When we were implementing this method at Codica, it took a week or so to prepare the developers for the next step.

Move on to Fibonacci story points

Story points evaluate the relative effort of work in a Fibonacci-like format: 1, 2, 3, 5, 8, 13, 21. This method is helpful as it forces the developers to make more accurate decisions within the scale of complexity. Here are a few reasons to use the Fibonacci scale.

• Using Fibonacci is helpful because larger story points (i.e. stories of size greater than 8) can be grouped to the nearest estimated Fibonacci number of the corresponding bucket in the backlog.
• In the case of small story points, the bucket difference is small. The final cost of resource and time could be finalized more accurately.

This approach is simple, as we just utilize 1, 2, 3, 5, 8, 13 numbers to estimate work. According to the previous relation, the largest task would be related to 13 or 21 story points.

Tip: At this stage, you need to discuss with your team what number will suit each task better. It depends on evaluating the task’s complexity, as well as how many difficulties they can face when working on it.

Once you see it is easy enough for the developers to use this method, you can move forward the time logs statistics. With its help, you can get the real numbers simply calculating the time spent on each task.

As a result, you don’t need to play a guessing game, multiply an estimation by Pi number or use a rule of thumb. Your dev team provides you with as sharp evaluation as possible.

The results achieved

Through using these agile methodologies, we have improved our dev team estimates. The main result attained is the implementation of a simple system that allows developers estimating with higher accuracy and stress-free.

Furthermore, here is a full list of improvements in the working process that we have achieved by adopting the mentioned above methodologies:

• Strong metric performance in estimate accuracy.
• A minimum error in project tasks estimation.
• Our dev team has formed a habit to consider risks during estimation.
• Acquisition of estimation practice in T-Shirt sizes and story points.

As you can see, the agile methodologies are an opportunity for the development team to learn to estimate the tasks efficiently and overcome the psychological barrier. Within the described system, you save much time when the customer cannot set the accurate technical inquiry and you are forced to make it when the development is about to start.

To summarize, we have successfully introduced a project estimation approach, which enables our team of developers to provide customers with an effectively organized feedback.

Want to see how this approach helps us deliver great products? Check our case studies.