Agile Project Estimation Challenges

The project management triangle combines three elements — scope, cost, and time. No project will be successful without a preliminary estimation of the three constraints that define quality.

How do you estimate a software project? Why is estimation important in agile environments? Is it possible to provide a customer with precise time and budget estimations? We outlined the main challenges development teams face at the product discovery stages and during early communication with the client.

The Purpose of Estimation

Why project estimation is important? This seemingly simple question can cause much confusion and lead to failed plans and wasted money. Project work should be based on planned timelines and have systems of assessment and reassessment of resources. Otherwise, the working process turns into chaos with no clear goals and hourly pay for no results.

Most people think the objective of the pre-project assessment is to figure out how big the project is and how long it will take. Although it’s true, there are other influential reasons. Scrum.org singles out three main purposes of estimation.

1. Estimations help the team understand if a goal fits a Sprint or needs to be broken down into smaller items.
2. Estimations allow business analysts and developers to forecast better.
3. And most importantly, estimations help you see if the whole thing is worth the investment.

The customer pays for the result but not for meetings, tech people’s time, or the project manager’s excuses. 13,000 hours of product development would not be worth the budget if the product is “raw” and barely functioning. The customer will only evaluate the product quality. The lack of a project assessment system always leads to implementation problems.

📌A project evaluation system is a set of processes and instruments used to assess, analyze and document the project’s scope and duration based on the requirements. It includes an evaluation of the project’s main stages and crucial elements.

If the project costs as much as its result, and the result can be achieved in different ways, then the development team can significantly affect the final price by changing the way of project execution or practicing specific project management methodologies. But again, you need a thorough analysis to choose the most appropriate and efficient approach.

The purpose of the estimation is to determine a deadline. Customers often want an estimate like, “We’ll work on this feature for two weeks, and your app will be ready in a month”. However, we work in the complex domain (according to the Cynefin framework, a conceptual decision-making model) with low predictability.

The purpose of the estimation is to discuss all the risks we may have, how difficult the assessment is and how big our task is. Even after discussing all this, we have every chance of making a mistake because we live in an unstable, ever-changing environment. We may have new requirements from external regulators, change the team’s composition because someone suddenly fell ill, or our vendors may not provide the delivery on time.

Anastasiia Musil, Scrum Master, Rocketech

Absolute Estimation vs. Relative Estimation

Imagine you have a new restaurant open in your neighborhood. It offers large and small portions of chips. Most likely, you’ve been to restaurants like this many times and can order the right amount of food without asking how many grams of potatoes are in the big portion. You might ask the server how big a side salad is and watch them spreading their hands demonstrating the size of the dish. In such situations, you place an order based on a relative rather than an absolute size. You’d order “a big portion” or “a large soda” rather than “400 g of soda and 170 g of potatoes”.

Similarly, you can evaluate user stories or features in an agile project. When ordering a large soda at a restaurant, people usually don’t know the exact size they’ll be served. But they know that a large soda is twice as big as a small one. What you need to know for a software development project is whether a specific story or function is bigger or smaller compared to other stories or functions.

💡 One of the main challenges of this approach is how to determine the project’s complexity. Is washing a panda bear at the zoo more complicated than washing a cat at home? Which factors come into play?

Hours vs. Story Points 

The classic waterfall project methodology in software development doesn’t allow for beginning a new stage before finishing the previous one, creating a linear progression. Organizations using the waterfall approach usually have a strict division into departments: development, design, analytics, etc. The requirements specification gets more and more details as it passes through each department.

In the past, such estimations would provide clients with “man-days” and a particular number of hours each specialist would require to finish their part of the project. Many companies still believe that this approach allows them to make precise forecasts.

As the industry developed, leading professionals had to come up with more progressive ways to better assess complex, multi-level projects. That’s how the story point approach estimation appeared. 

• Story points are relative units measuring the total size of a user story, function, or other parts of a project. When using this size unit, the development team assigns a certain number of points to each element.
• A two-point story must be twice as large as a one-point story. It should also be two-thirds of a three-point story.

The purpose of using story points calculation in Agile is to compare tasks with each other based on existing knowledge and previous experience. You look out the window and focus on neighboring buildings. It’s much easier to define which buildings are tall, short, or mid-size rather than trying to figure their height in meters in your head. 

The biggest challenge of this part of the journey is that customers typically don’t understand the concept and force the team to make rough hourly estimations nonetheless. Some specialists believe it’s a matter of the generation gap and consider the waterfall and hour-based approaches outdated.

Story points are not about fashion trends. Estimating hours of work is even more inaccurate. When we say a task will be completed in three hours, we can’t know that there will be no electricity or an emergency within these three hours.

To avoid this unpredictability, many teams move to the story point estimation. It considers risks, complexity and scope — the three factors used for comparing tasks.

And if we know that during the past Sprint, we were able to close 20 story points, we can plan the same number for the next Sprint. We make a prediction based on a comparison of the three factors. But some teams start converting the estimates into hours for old times’ sake, saying that two story points equal a day of development. And here’s the problem: what takes a day of work for a mid-level developer will take only a few hours for a senior specialist. The same task will occupy a junior for a week and may involve the rest of the team helping the newbie.

Anastasiia Musil, Scrum Master, Rocketech

Estimation Equals Commitment

One of the biggest challenges and sources of misunderstanding between customers and custom software companies is a misconception of estimates. Some tech vendors try to assume all possible risks up to an alien invasion. This approach usually leads to longer planned times and larger budgets. Although customers are happy to get the product quicker and for less money than expected, there are better ways to do it.

Estimation equals commitment. Unfortunately, it’s not how it works, especially when starting a project from scratch. When the team is just starting, we don’t know our speed yet. We don’t know the product and the difficulties that may arise. The estimation’s purpose is to discuss a particular user story, what’s expected and how to do it with the Product Owner and the team. This way, we make a forecast. But it’s approximate. We improve our ability to predict with each Sprint because we see how much we actually manage to realise in the previous sprints.

Anastasiia Musil, Scrum Master, Rocketech

Overcoming Uncertainty

What are the biggest challenges in software development project management? The very first difficulty many companies meet is accurate project estimation. Simple as that. Most clients want to see precise numbers like “X months” or “X thousands of dollars/euro/pounds” without realizing that any forecast is only approximate and involves much more factors than just “a five-people team will be working for 248 days”.

However, it doesn’t mean you’ll get a vague quote with no liability. At Rocketech, we know that experienced teams leverage different project estimation techniques and understand the value of the client’s time. Agile story points estimation methods fit our approach best as we base our expertise on years of experience working on diverse projects across industries. While collaborating exclusively with professionals of the Middle+ and Senior levels, we have built an effective project evaluation process aimed to minimize uncertainty and mitigate possible risks.