10 Techniques for Estimating Software Projects

Software development estimation.

One of the hardest things in software development:

How do you know how much you need to build a software feature? What are your chances of finishing on time and under budget?

Some estimates are over-estimates. Some are under-estimates.

Every now and then, they turn out to be just right.

But is there anything that you can do to be right most of the time?

In this post, we will focus on the ten most popular software development estimation methods that successful software developers use to accurately estimate projects.

You’ll learn about estimation techniques like planning poker, story points, and Delphi method. These methods are easy to implement and provide valuable insight into your projects.

But before that, we will look at why are estimates so important in software development and how you can use them to grow your career as a software engineer.

Software Development Projects Life Cycle

Before you jump into estimation, it’s essential that you have a solid understanding of the software development life cycle.

How is software developed?

SDLC focuses on the following phases of software creation:

• Requirement analysis
• Planning
• Software design
• Software development
• Testing
• Deployment

There are many ways to carry out the SDLC cycle.

Popular SDLC models include the waterfall model, spiral model, and Agile.

What do they have in common?

They all care about some kind of estimation.

Although the modern approaches to software development life cycle differ from the traditional waterfall model, the project estimation still plays a key role in both models.

In software development, estimation is a key part of the project success. It helps establish realistic expectations and timelines for stakeholders, developers, designers and testers to ensure that everyone understands what's involved in the project.

Analyze different aspects of software development project and what it takes to get them done because all of them will be an enormous factor in estimating the project.

Effort Estimation and Parkinson's Law

Parkinson's law, also known as the law of triviality, states that "work expands to fill the time available for its completion."

People will often estimate the amount of work on a project and take just enough time to complete it. Even though the work could have been completed in less time, the extra time will be used for other tasks.

This often happens subconsciously with little thought.

This law states that the more time you have to do something, the less likely it is that you will get around to doing it. It's better when people only have a limited amount of time, but they still might leave things for later.

To combat procrastination, try to:

• Break the project into smaller tasks.
• Estimate the time for each smaller task.
• If any one of those tasks takes more than a day, break it down to subtasks.
• Work on only one task at a time.
• Set your own deadlines and hold yourself accountable to those deadlines.
• Make it clear what is expected at the start of a task, and when you'll be done.

Use it to your advantage

Why is it that majority of soccer goals happen in the last minutes of the game?

Urgency. When the game is on the line and time's running out, teams take every opportunity they can because it might be their last chance.

Many situations in software development are like this. When you're working on a project, and the deadline is fast-approaching, it's likely that you'll work harder than when the deadlines are not approaching quickly enough.

Use this phenomena to your advantage by holding yourself accountable to deadlines.

Elapsed Time vs. Ideal Time

The trap that teams fall into when estimating software development efforts is trying to measure the elapsed time instead of converting it to "ideal" or "committed" time.

Although a day has 8 work hours, a software developer cannot commit them all to writing code.

Consider the following reasons:

• Time for meetings, emails and other distraction
• Breaks
• Emergency interruptions (things come up)

The result is a lot of time spent not developing.

Therefore, it's important to convert the elapsed time into ideal or committed time.

Take your approximated average work hours (in a day) and divide them by "ideal" or "committed" days in order to get accurate estimations of software development effort.

When you're calculating an estimate in hours, make sure that the number includes only committed days and not any unplanned interruptions.

Estimate a sprint backlog in ideal hours (which are essentially the time it would take to do without distractions) rather than elapsed times. That approach helps engineers to make a better judgement about what is achievable in the sprint.

The Fibonacci Sequence

The Fibonacci Sequence is a famous sequence that shows up in many places in nature - from the petals on flowers to our own human DNA.

1, 2, 3, 5, 8, 13, 21, ...

The Fibonacci Sequence approach is often used to estimate software development projects because numbers that are too close to one another - like 8, 9, 10 and 11 - are impossible to distinguish as estimates.

What's the difference between an effort of 9 and 10?

It's hard to tell. But the difference between 8 and 13 is unmistakable.

Weber’s Law says that people can tell the difference between two stimuli only if they are over 60% different in intensity.

Mike Cohn explains the weber's law in action:

Imagine being handed two weights—one is one kilogram (2.2 pounds) and the other is two kilograms (4.4 pounds). With one in each hand but not able to see which is which, you can probably distinguish them. The two kg weight will feel noticeably heavier. Imagine instead being handed a 20kg weight and a 21kg weight. They are the same one kg difference as the one and two kg weights. But you would have a much harder time identifying the heavier of the two weights.

The Fibonacci Sequence is great for distinguishing between intensities because each number in the sequence is approximately 60% larger than its predecessor.

1Bracketing

Bracketing is a quick and straightforward way to get an approximation to estimate software development. Even with no previous experience in estimating projects - you can quickly come up with ballpark figures that will help shape decisions down the road when more details are needed or available.

To start off with bracketing, you will need to make some basic assumptions about your project, and then take a guess at how long it would take.

For example, if you are developing an Android app that is similar in scope to Instagram, assuming five developers will work on the project full-time, we can define the brackets as:

• Low: two months
• Medium: four months
• High: six months.

Then ask, Which bracket fits the estimation more closely?

The most important thing about bracketing is to understand that it is a very rough project estimation that will probably change as the project proceeds and the team reveals more details.

The goal of bracketing is to find a general area of what your project will take, not come up with an exact number that needs no change.

2Delphi Method

The Delphi method is a group forecasting technique. It is also sometimes called the Delphi technique or consensus estimation.

The key idea behind the Delphi method is that an accurate forecast cannot be made by one individual, but small groups with diverse knowledge and perspectives will have more accurate estimates.

The project team aggregates results and improves on forecasting each iteration.

The small team of experts share their estimates on how long it would take them to complete any given task and anonymously submit said estimate without communicating with one another first.

Sharing estimation anonymously helps avoid biases caused by peer pressure, which can lead rational estimators into systematically underestimating time or overestimating time, depending on where they stand within the system of power dynamics present among peers during discussion.

The facilitator then shares these anonymous estimates publicly before requesting for experts to adjust accordingly based on what they have shared so far. The process continues until they reach consensus and all estimations are within a reasonable margin of error.

3Planning Poker Technique

The Planning Poker Technique is a group estimation technique that helps software developers come up with accurate estimates.

Software developers are each given a deck of numbered cards, one for every potential estimate they could give on the task at hand.

The numbers range from very low to high in increments of five or ten. Each card represents a different estimate.

Software developers then take turns drawing cards, going around the group and sharing their card's estimates with one another.

The person who draws a high number on a given turn is typically challenged by someone else to defend that estimate before it can be selected as the final answer.

The technique helps software developers come up with more accurate estimates because it forces them to back up their estimates with justification. Drawing cards at the same time prevents group thinking and helps avoid the cognitive biases of anchoring and availability heuristic.

1. The team takes a time boxed period to discuss the user story and go over all the acceptance criteria together. Make sure that team members do not share estimations with each other to avoid bias.
2. Team members place their cards on the table face down. The number on the card represents estimated effort for the user story.
3. Team members simultaneously reveal their selected cards.
4. Discuss. The power of card estimation approach is in discussion that comes after the estimation process. If there are big differences between the estimates, discuss why there are differences. If the team member is not confident about a particular estimate, revisit that user story and revise it until they are satisfied with their estimation before continuing to other estimations.

4Extreme Programming: Planning Game

The extreme programming planning game is a great estimation technique because it relies on teamwork to encourage estimators to be honest with their estimates.

Team of developers and stakeholders come together to plan release planning and iteration planning.

Release Planning

In Release Planning, the customer and developer are both involved in determining what requirements go into which near-term releases. It includes exploration, commitment, and steering phase.

Exploration phase is where the customer and developer work together to create a plan for near-term releases.

Commitment phase is where the team commits to what they have agreed upon in Exploration.

Steering Phase is where they make any changes necessary after committing through feedback from stakeholders or customers.

Iteration Planning

In Iteration Planning only developers are involved in determining what requirements go into which near-term iterations. It includes exploration, commitment, steering phase.

In the Exploration Phase phase, developers will work on translating user stories into tasks. User stories will be translated into tasks by identifying near-term phases and the scope of work that needs to get done in those phases.

Commitment Phase is where the team assigns the task created earlier to developers.

In the Steering Phase, developers will make any changes necessary after committing through feedback from stakeholders or customers.

Extreme programming planning game shows that estimation is a social process and not an individual one.

5Work Breakdown Structure

Work breakdown structure (WBS) is a visual outline that breaks down the project into smaller, more manageable portions. This diagram allows developers to work backward from the final deliverable of a project and identify all activities needed for success.

A WBS is a project outline that lists all the steps of a project in an organizational hierarchy. The deliverable is listed at the top of the diagram, and below are levels that break down how those phases and tasks will be done to complete the project.

Think of a project as an onion. You peel out the layers and find smaller onions inside, until you get to the center core—that’s your deliverable or final goal.

Focusing on well-thought out WBS can help you organize your thoughts when estimating effort for software development projects as it breaks down each phase into manageable chunks which helps estimate time per tasking item more accurately than if they were not broken down.

How to Create a Work Breakdown Structure

1. Define the project goals and objectives before assigning tasks to software engineers or asking them to estimate their own workload for a project.

2. Break a big project into phases.The size is up to you, but try to keep the individual phases manageable enough so that software engineers can estimate their own work.

3. List deliverables and what needs to be done in order for them to get completed.

4. Break a list of deliverables into tasks.

5. Assign each task to software engineers, who will then estimate the time it'll take them to complete that task.

6Story Points

Story points is a software estimation technique that is popularized by agile development teams.

Story points are usually used for epics and user stories but can be applied to any type of task in software development projects.

The idea behind story points is to estimate the work using relative units on a numerical scale.

Teams often use story points in place of time estimates because story points are relative to the complexity of the work. The benefit of using points instead of hours is that story points tell how much effort a product backlog item will require, relative to other product backlog items.

For software developers, points are useful because they are relative to the complexity of software development.

To try to match Story Points to hours ignores the complexity of sustainable software development. The number that matters is how many Story Points a team can complete in one sprint. This gives you insight into the efficiency and capacity of your team.

7Sprint Velocity

The sprint velocity is the amount of work completed in an iteration. It helps teams identify and resolve problems early on, potentially saving days or weeks later on down the line.

You can use Sprint Velocity to estimate a project by using past data from the team's velocity and adding an estimation for work yet to be completed.

The development team's velocity is calculated by adding up the total number of story points that were completed in an iteration.

The team should use its past performance to generate an accurate estimation for future work, so they know how many sprints it will take and what sprint velocity would lead to successfully completing those iterations.

Keep track of your velocity throughout the iteration. The simplest way is to look at the burn down chart. If you get stuck, it's best to review the tasks that are still open and reassess your estimation.

8Relative Prediction

Relative prediction is a project estimation technique where you estimate the work effort for your project by comparing it to another similar project.

Relative estimation requires an understanding of how long other projects with similar scope and complexity took, so that estimate can apply to this new project.

It is essential to have the right estimation data and that we are comparing like-to-like projects. The relative data points should be from projects of a similar type, so you're comparing apples with apples.

Project managers often take into account relative prediction alongside other estimating techniques in order to achieve more accurate predictions of project effort.

The downside to this approach is it doesn't account for any changes between your project and another one, so you may underestimate the effort required.

The team needs to have good documentation of past projects, and ideally the project manager should talk with team members who worked on those tasks.

Only experienced teams should use relative predictions because it relies on past data and the ability to use previous experiences which many junior engineering teams don't yet have.

9Estimating with Tee Shirt Sizes

If you notice people are getting hung up on how many points a story has and this is not adding value, switch to a system that isn't numerical. For example, using the tee shirt size method.

Small, Medium, Large, and Extra Large represents the effort needed to get a task done.

Estimating with Tee Shirt Sizes is a great way to get started with estimating effort.

The relative difference between T-shirt sizes reflects to the effort.

This relative difference means that a Medium is about twice as much effort as a Small, while an Extra Large may be three times more than what's needed to do a minor task.

Although the sizing of t-shirts is not a perfect system, it helps project managers quickly grasp the relative size of their higher-priority items.

Tee shirt sizes are not like numbers, they do not go together. You cannot use them to find out when you will be done or how much you can build in 3 months.

The two big downsides of the T-shirt estimating method are different views of the size and lack of mapping to time.

Team members can have different views on what each size represents. An extra large task would be the equivalent of a small for one team member and a medium to another.

What does it mean that task will take XL size? There is no mapping to time.

If you want a more accurate estimate, then it's best to use the T-shirt method as an initial estimation and adjust accordingly with other methods.

10Use-Case Points

Use-case points is a software development estimation technique that uses point values to estimate what it will take in time and resources to complete the project based on the size of each user story or requirement.

In this approach, point values are calculated by taking into account how often and in what manner an actor uses each scenario, as well as technical and environmental factors that may affect user experience with a product. The point value is then abstracted through mathematical equations, which can be used for comparisons within or between other projects.

Use case points measure the size of an application. Once we know the approximate size of an application, we can derive an expected duration for the project if we also know (or can estimate) the team’s rate of progress.

The time it takes to complete a project changes depending on:

• The number of steps to complete the use case.
• The number and complexity of the actors.
• The technical requirements of the use case such as concurrency, security, and performance.
• Various environmental factors such as the development teams’ experience.

and knowledge.

Read more on how to improve estimation practices by applying use case models.

Think About Unknowns in Software Engineering

Software engineering is full of unknown unknowns, things that you don't know that you don't know. Or is it?

After all, code defines software, and code is a language that we can interpret, read, and understand.

If you're writing code for a software project, then the unknowns of your project are probably in plain sight - they just haven't been uncovered yet.

Take the approach of uncovering the unknowns that you think are in your project instead of estimating blindly.

Ask yourself: "What is the unknown? What is it I don't know?"

When you start out, there will be a lot of unknowns, but as you uncover them and learn more about the project, the list will get shorter.

It's not that software development is full of mystical unknowns, it's that YOU haven't discovered them yet.

Help yourself stay on track by marking off what you uncovered or resolved throughout development. This way, you can be confident that your estimation is accurate the next time around.

Ask questions. Every time you see a piece of code that you don't understand, ask yourself: "What is the purpose of this code? Why does it exist?". Then find someone on the team who can help you answer those questions.

Estimating projects takes careful work and diligence. It's not about guessing; it's about analyzing all aspects of a project and using previous experience

What To Do When Your Estimates Are Wrong?

Estimating is one of the hardest thing about software engineering.

The key for dealing with estimation issues is to communicate.

If a project is not going the way you expected it to, communicate with your team.

The sooner you communicate, the better. There are many people involved in software development project, and if you are able to communicate with your team early on about estimation problems, it will allow them time to come up with solutions.

Don't be afraid of making mistakes; we all do it! The important thing is that you learn from them and try your best not to repeat them in a future project.

Make it a learning experience and don't be too hard on yourself.

Reflect on Your Estimates

The feeling of disappointment when you miss an estimate can be hard to swallow.

We all want our estimates to come true, but sometimes they just don't pan out that way and we need honest conversations with ourselves to figure out what went wrong.

The first step is honesty with yourself how you made your estimate:

• Did I underestimate the complexity?
• Was there a change in scope midway through that increased my workload significantly?
• Were some tasks easy and done quickly while others took too long?
• Was I working on this project alone or with a team who could help me out when necessary?

Engineers and engineering leads throw their hands up in frustration when confronted with why estimates are difficult because they're too many unknown variables to account for.

However, if we plan ahead by considering all possible scenarios without being intimidated or overwhelmed by what might happen throughout development then engineers can get a general idea about how long it should take to complete any given project which makes estimating easier despite there still being some uncertainty involved.

Giving estimates, than missing them forces deeper reflection and faster learning about the types of unknowns in the software world.

When you end up giving estimates, then miss them by a large margin, you cannot avoid having an honest conversation with yourself and your team.

• What did we miss?
• Why did we miss it?
• How can we try to account for it, the next time?

Master the Estimation Skill To Grow Your Career

Remember that estimating takes practice. It's a skill.

It's an integral part of software projects, so if you master it, you'll differentiate yourself as a valuable developer.

In this blog post we covered a wide range of estimation methods that you may find useful in different situations.

With so many tools and techniques to choose from, it can be hard to know which ones are best for your team's specific needs. As you work on your next estimates, think about which technique would fit you the best.

It doesn't matter if you're new or experienced in the industry, these methods will help you accurately estimate your project's timeline. So stop wasting time guessing at how long things will take and start using one of these ten techniques today.