Project estimates: the basic methods making predictions accurate

Estimating a digital project is an important task for any software company. Trying to build the proper calculations, some teams miss crucial points for future project success. With this article, we share our experience in this task performing that can help other teams to avoid missing the budget and time. 

The ways the estimate calculations can be failed

There are several ways the developers’ team can commit an error while estimating the tasks, such as:

• underestimation;
• hyper estimation;
• missed risks. 

Each of them has different reasons though lead to similar consequences in the lost project. 

In case the business chooses the particular team they are going to cooperate with, the hyper estimation can make them feel misled. When getting several estimations on hand, they can parallel them and see a great difference. So the question arises – who is wrong with their calculations, and which team’s paradigm and experience give a more professional view. As a result, the bigger estimate is repelled, even if it appears to be more realistic in reality. How to avoid this effect – we describe below. 

Most fails with incorrect estimation are about underestimation and further failing of all possible deadlines. Both in time and money. Incorrect calculation at the end of the project can lead to the following:

• the business can not get their product in time, as it was planned;
• the developers try to provide the product in time and work in hush;
• the number of bugs grows exponentially due to the rush when no time is left to fix them;
• several functional parts of the product can be postponed resulting in a weak MVP.

This situation grows as the snowball and causes similar failures in the adjoint projects. What is sadder, the companies often do not know how to break this circle. They stop the activities, though the paradigm stays the same, so they are basically doomed to the same mistakes with the estimation of the next product. 

Appealing for a new way of thinking about estimation

To get the proper direction and break the circle, several things should be changed in the minds and general approach to the project. Before starting the subsequent estimation, try to bear in mind the following points:

Failure is part of the road and the first step to success

When making something big or new, each can make several mistakes and not only because of the lack of knowledge. Especially if you take into account Murphy’s law – Anything that can go wrong will go wrong. Understanding that at least 30% of what is planned can go wrong enables adding that time to estimate. 

Quality can become a pain in the back for the project flow

Though the provision of a high-quality product seems to be a primary goal of any team of developers, they often cut the costs in this area to make estimation lower. As a result, the final product becomes weak and non-competitive, or deadlines move further to ensure a sufficient level of quality code. More crucially, quality issues are often revealed at the end of the project development process, when no budget is left for massive changes. Emphasizing a big part of the cake to the quality should become a Must for any team willing to get good products and satisfied customers. 

The planning fallacy is a factual cognitive paradox

People tend to repeat mistakes in planning repeatedly. When the previous plan failed, the next one would not surely be totally correct. Testing of the different tasks performing under various conditions can prove or deny theories. As a result, with empirical methods, a team can get the real timing needed for this task. Sometimes it is better to believe numbers mapped on the paper than single assumptions in the person’s mind. 

Estimate-building approaches for different business tasks

Regardless of the chosen approach, estimation is a process of guessing the future. It can not be accurate since each project and its environment is too unique. The overall process can be at least controlled, and as the result, allow the introduction of changes on the go. 

The approaches vary according to the methods of project completion. Agile and waterfall models define the particular steps each team takes to make the estimate predictions as accurate as it is possible.  

The agile project estimation process

With the agile approach, the teams should divide the entire project into separate user stories. This methodology expects that all sprints take similar periods to be completed. As a result, the team should define how many user stories or tasks they wish to add to a single sprint. The requirements should be separated into measurable units that complete sprints. 

No user stories are of the same size, so the task of the team is to compare them with others and place them properly to ensure flow effectiveness. We prefer to use relative sizes of the tasks rather than the actual time needed to perform them.   

To avoid subjectivity, the teams often apply gamification and scale the user stories in numbers. Each story receives its respective story point, depending on its relative size. The bigger number – the more effort needed to complete the task. One sprint can contain only a particular number (e.g. 15), and by summing up the smaller parts (1,2,3,6,7), it is possible to understand which tasks should be shifted further in sprint planning. And sometimes, too big tasks should be divided into parts to fill a sprint perfectly. 

When assigning the points to user stories, consider the risks and additional costs in all pieces of the project. If a story is too uncertain, that is the reason to add points to its number. As a result, though being still subjective, the evaluation gets objective and relative points. That allows making fewer mistakes in future. This game helps to switch the monotonous and stressful planning process into something more interesting for the entire team. Grasping other aspects of the development that do not belong to the coding itself is a positive point as well. 

It is crucial to control the completion of the stories within a single sprint. Carrying the dept from sprint to sprint can threaten the success of the entire project. At the moment no credit is given to the completion of the tasks, the time needed to finish the circle is calculated. Then it is repeated until the entire project is ready.  

In case the sprint has some spare time, it is possible to do some extra work, but not to start doing the tasks from the next sprint. 

The team analyses the results of the tasks completed in the previous sprint and performs the future estimates with the respect to this data. Experience builds all future assumptions that will appear under the same conditions. 

The errors teams often make while dealing with the project estimate in agile methodology: 

• the desire to go everything faster than it should be done;
• avoiding to shift a task or temporarily replace a person performing a task if they suddenly disappear from the process;
• placing too many tasks at one person or creation stressful situations within a team that lead to fast burnout; 
• giving no time to intermediary testing;
• inability to calculate the scope of the particular efforts needed for the sprint finish. 

Waterfall project estimation process

The waterfall methodology expects that the team calculates the entire project scope from the start. They compare the requirements of the client and their previous projects to reach this effect. 

First of all, when starting the estimate, the business should provide all requirements for the future product. Even having all functional scope listed, most forget about minor tasks. But when there are many of them – the final time for their competition can crucially shift all deadlines. Even the tasks that seem simple can be separated into smaller underestimated parts. Though, experienced teams know that behind the creation of a “single small icon”, the numerous actions are hidden for everything to work correctly. 

Then the estimate receives another layer of timing – periods needed for planning and management. Some big and complicated projects consume up to 50% of the entire project’s time on the activities behind the initial coding. Among the others, they include:

• market or target audience researches;
• various quality checks (from UI and UX to architecture checks);
• security and data protection measures;
• preparation of the environment before deployment;
• various discussions and analysis about the project’s current state and the next features planning.

They all are a core part of any project, though, require time that is usually omitted or left behind the scenes. 

Besides timing needed to ensure high quality, market presence and scalability of the product, numerous risks can appear from nowhere at any time. The ability to predict risks can become the defining characteristic for a person creating estimates. The teams should not fall into a pessimistic mood, though be ready that something can definitely go wrong. 

Not to miss a piece, it is better to perform calculations in a single table. All major stages should be stated there, and based on the previous experience, the team assumes the time needed to perform similar tasks. They note hours in the table, and can easily add the fork for each task or subtask. That means that the team makes the best case predictions and the worst case. The time in the lower and upper sections can sometimes differ up to 50%. 

Moreover, noting down the precisely combined table will help to prove the numbers with managers or business. It would be easier to perform further assumptions, having the ready-made analysis of this data. More transparency helps to build trust and understanding of the situation on the project. We mentioned the situation with hyper estimation previously –  building the tables with arguments can become the solution to it. 

The errors teams often make while dealing with the project estimate in waterfall methodology: 

• ignoring the difficulties in working with the legacy code;
• inability to calculate risks when working with new methods or techniques;
• inability to accommodate to the fast-changing requirements to the product the business arises periodically; 
• trying to save some time on “supplementary” and non-coding activities.

Prompt way of estimating

This option is not the best choice if the team truly wishes to get a good project. Though some teams still use it in their activities, so here it is. 

The approach of brutal estimation deals with bracketing. It is the main, and probably the only advantage is that it is done fast. Sometimes even too fast. The person estimating the project chooses the particular brackets and paces the project into one section. As a result, the mismatch is too uncomfortable for both sides – developers and business. 

Before making the brackets, each person making an estimate should provide answers to several questions:

• Has the team faced similar projects in the past?
• What was the team composition for that project?
• What difficulties or failures did they face with that project?
• How long did it take to complete the project?
• What is the gap in the functional scope of these two projects?

Only after getting sufficient answers, the person can predict the approximate scope for the current project. Even though adding from 50% of the predicted scope is a good thought for a final scope. Haven’t we signified that coffee cup reading is an option for brutal estimates as well?

One interesting moment, stating the range from 20k to 30k, the business will definitely be sure that the team is going to succeed in 18k. And then comes the crude reality with its 40k. And hopefully, if the business will not leave the team after 22k for such elusive predictions.  

It is possible to avoid the fixed price pit if to work on a price-and-material basis and calculate the scope in features developed. Stating the number of features done to the particular deadline can help to deal with stress. Especially if to separate the features into essential (MVP-stage) and supplementary ones. This places the focus on the core of the future product allowing to develop it fast. 

What to consider in estimates regardless of the chosen methodology

There are a bunch of activities each team performing an estimate should consider not to fail further. 

1. Listen to business requirements. The personal assumptions of PMs or developers of what the business might wish to get – is the road to nowhere. 
2. Ask the business for more details as possible. If the requirements look like “I wish something like Apple”, the result will definitely not be like this. Conclude documentation.
3. Ensuring the team gets the task, understands the business and their final user or market enlarges the chances to get a good product in the result. 
4. Do not miss the subjective assertions to the project composition and experience of the team.
5. Act as a team when performing estimates. Listen to each member and be ready for middle grounds. 
6. When trying to find the balance in the desire to satisfy the business and get realistic numbers, give preferences to realistic numbers. Underestimating the result will not bring happiness to the business in the end. 
7. Reaching for perfection, remember that the target is to reach the goals, but not the stars. Something definitely will go wrong with the project, and that is kind of normal. The major objective of the team is to make the number of unpredicted items and the size of the gap between the best and realistic scenario as small as possible. 

These are the main ideas each team should bear in mind when creating a good estimate that can be implemented in future with coding. Remember that each product helps to get more experience and perform the next estimations with better clarity. As a result, the team of developers gets better projects and more profits when doing everything wisely. 

Make the first step on this long-lasting road yourself, or submit to us your ideas and we help you to achieve your goals.