The risky art of estimating: Where and how estimates for project delivery come from
Find out how estimates for software delivery are created, what are top 5 popular methods for estimating projects and more.
In IT and business, spontaneity is not the way to go. Planning is the alpha and omega of success. Everyone wants to know when the project will be done and how much it will cost. The CEO, the team (so they can plan their holidays), and of course the clients who commission the project.
If as a client you sometimes feel that your software vendor is pulling those estimates out of the hat, then we’ve prepared this article specifically for you. We’ll reveal what’s behind the seemingly random numbers and show you the 5 most common methods we use to make estimates here at Siesta. On top of that, you’ll see that estimating is a risky and unpopular activity, and hopefully, you won’t judge your project manager so harshly the next time the original estimate is a little off.
What is included in the estimate
No one can give you an exact estimate at the beginning of a project. All the dates you get are approximate. The more complex and experimental the project, the more challenging and risky the estimating discipline is.
In addition to the development itself, a good estimate also accounts for the following items:
- capacity of people in the team (they often work on multiple projects at the same time, they can get sick, take time off)
- requirements analysis
- planning
- project architecture
- project management (15-20% of the total estimate)
- meetings (internal team meetings and those with you as the client, usually 10% of the total estimate)
- bug fixing
- risks
- subcontractors and their capabilities and operation
- tools and software required
- other resources
And any of these items may increase during the development of the project for various reasons. Now you’re probably beginning to understand why estimating is such a risky discipline. And why, according to a McKinsey study, up to 66% of development projects fall short of their original estimates (budget, deadline, or scope). We’re happy to say that at Siesta, despite all the pitfalls, we deliver over 90% of our projects on the agreed time.
Estimating in agile vs waterfall
The estimation process is fundamentally different in agile or waterfall projects.
In waterfall, you have a given project scope and then you estimate time and cost. In agile management (which we use for 90% of our projects at Siesta) it is exactly the opposite.
Projects managed by the waterfall method are significantly more prone to delayed delivery due to their rigidity. It only takes one setback to significantly delay the team and all the subsequent phases take on delays. And then there’s no chance for recovery. This is easier to avoid in agile management because individual team members and project increments don’t usually depend on each other that closely.
Estimation methods aka where do the numbers come from
So where do the numbers that you as a client ultimately receive? We’ll introduce you to some popular methods used by development teams and show you which ones we use most often at Siesta. In other words, you’ll see where the numbers that your project manager presents to you come from.
1. Qualified estimate
The most straightforward and quick method to get an estimate. But it has its own risks.
We ask the developer how long they estimate the task will take. So it is an estimate of effort.
Then we add a contingency. We always add that to the original estimate. The time reserve or buffer can be in the order of 20 to 200%.
The contingency depends on:
- The quality of the developer’s estimate. If we know from experience that the developer underestimates their estimates by about a third, we simply multiply their estimate by a third.
- The developer’s experience. Senior developers are more confident in their estimate. They already know what to watch out for. Junior developers’ estimates tend to be unreliable.
- The riskiness of the project. If we’re working with new technologies, solving a new problem, or working with a third party we don’t have experience with, the contingency must necessarily increase. The greater the unknown, the greater the contingency.
- Project size. The bigger the size, the bigger the risks and the bigger must be the contingency.
- The confidence of the project manager. If they are confident about their own work with estimates, then they just need to add a smaller time contingency and vice versa. .
From a psychological point of view, it is much worse to entice a client to an earlier deadline and not meet it than the other way around. Psychological anchors work too reliably on our brains.
Qualified estimate is the most direct method. But it’s only suitable
- in teams that have worked together in the past and know each other’s work pace and habits;
- teams with seniors who have experience in estimating and know what to look out for.
2. Analogy
The common sense method. If we’ve previously developed a similar project, we will reflect on its complexity and take into account the differences and project specifics.
Because every project is, by definition, unique.
At the very least, we need to take into account:
- who is working on the project – their seniority, motivation and capacity
- the client’s cooperation – often it takes the longest time to wait for materials
Analogous estimation only makes sense to apply when the team is
- in good sync
- and experienced.
3. 3-point technique
You’ll very likely receive 3 estimates flat out from your project manager.
- Pessimistic (p)
- Optimistic (o)
- Most likely (m)
Your project manager will then calculate their own deadline as follows:
(p + o + m)/3
(or divide by 6 according to the weight given to m)
Or you get the likelihood percentage from them for each scenario.
“With 50% certainty, we’ll deliver the project in 5 months. If we’re talking 8 months, then we have 80% certainty. With 90% certainty, we’ll be able to deliver it in 10 months.”
The 3-point method is often used by teams estimating in the late stages of development or when they are anticipating uncertainty. Or by those that don’t have much experience with the agile method.
4. Planning poker
Before we introduce you to the planning poker method, let’s first talk about the concept of story point.
A story point is a number on the Fibonnaci scale (1, 3, 5, 8, 13, 21, 34, …) that represents the complexity, including risk, and effort required to complete a given user story. The higher the number, the more effort-intensive the user story is.
The method of planning poker then goes as follows:
- The project manager selects a user story to be estimated.
- The team discusses the user story.
- Each team member then secretly selects a card with a given number of story points and prepares it face down.
- At the mark, all members reveal their card.
- The members with the lowest and highest estimates explain their choice.
- Based on the new perspectives, all members again select the card with the story point and reveal it on the sign.
- The process repeats until the team reaches a consensus. The goal of planning poker is not compromise, but consensus.
Planning poker can sometimes be time-consuming. But it is a great tool for team leaders to promote understanding within the team.
It is well-suited to be used
- in smaller teams
- and with a few user stories.
5. T-shirt sizing
It is a simple method especially suitable for Kanban managed projects.
T-shirt sizing is a suitable method
- for less experienced teams
- at the beginning of a project
- when only a rough estimate is needed
And how does it work?
- The individual user stories or tasks are divided into 5 categories: XS, S, M, L and XL.
2. Each size will be assigned a certain number of story points.
Best practice
Finally, we’ll reveal a few tips from our best practices that, along with more accurate estimates, allow us to plan and ultimately deliver a user-friendly product.
Prioritization
First, we break the big tasks (epics) into smaller ones. Then the small ones are easier to estimate.
Here, a reliable method for the initial selection is the MoSCoW method.
We sort all requirements by their RoI (return on investment) into 4 quadrants and focus on the Must and Should have. That’s because the Must have and Should have requirements together are supposed to build a competitive product.
| MUST HAVE the vital requirements for the project operation | SHOULD HAVE important but not vital requirements |
| COULD HAVE nice-to-have | WON’T HAVE low value and high RoI requirements |
Things to remember when estimating
A good project manager never forgets to allow enough time for bug fixing in the estimates. These are an integral part of development. Even the most experienced developers do not code error-free.
Finally, estimates need to be revised during development. After all, they’re still just estimates, not numbers set in stone. After all, during development, there are always new facts that need to be taken into account.