Effort estimation is a critical aspect of any software project. Depending on the context it may be a binding commitment with the client, it sets expectations, influences budgets, and can make or break deals. The risks and challenges associated with inaccurate estimation include scope creep, missed deadlines, budget overruns, and reduced team morale.
As engineers, understanding the best practices for estimating effort in software projects is essential for delivering value to clients and maintaining a competitive edge in the industry.
The following are a list of thoughts and reflections around this topic that I hope may provide insight and help engineers with a desire to get started with this practice.
It’s a hard problem; avoid it when possible!
“A strange game. The only winning move is not to play.” Joshua – War Games
Estimating the effort of software projects is a game of predicting the future with incomplete information. It’s a hard problem. Individual productivity varies significantly, ranging from 1x to 20x per person, which complicates the assessment of overall team productivity. Technology stacks and tools are constantly evolving, often changing on approximately five-year cycles. This rapid pace of change means that experience may not always be directly applicable, further challenging the estimation process.
It’s expensive timewise, and the potential for error remains high. Depending on the business context, this may not be a huge deal (pun intended). Sometimes landing on a reasonable neighborhood of total cost, and sizing the order of magnitude is enough. In other cases, it can potentially lead a company to bankruptcy. As such, the importance of accurately estimating effort in software development should not be underestimated.
Given this context, you need to ascertain first if you have enough information and context to proceed with the estimation exercise to determine if it even makes sense. In some cases, where the requirements are just too vague, context is rapidly changing; it just doesn’t make sense. Sometimes too little information is just not enough. Estimating effort without sufficient information is a recipe for disappointment.
In these cases, If crucial details are lacking, it’s better to either suggest a product discovery phase to gather the necessary data before committing to an estimate or propose to move forward with a purely agile approach, where planning is carried out on a sprint by sprint basis, adjusting for sprint velocity and there’s no hard commitment to a total budget. These options allow advancing while preventing setting unrealistic expectations.
Product Discoveries can be thought of as mini projects whose goal is to gather information, elicit requirements, get a good grasp on the scope of a project provide a much better foundation for an estimation of the effort required, and minimize risk for all parties involved.
Understanding Business Context
Whether it may be for an external client or in-house product development, there’s always a business context that frames the possibilities of the project. This context involves available budgets, organizational risk tolerance, quality and timeframe expectations, possible team compositions and their productivity, etc.
It’s often the case that estimations are required in bidding rounds that foster price-based competition scenarios. In these cases, clients tend to focus on low price when selecting the winning bid generating an incentive for underestimating efforts.
It’s key to understand as early as possible the game being played. What are the expectations for the estimation? Ballpark? Ceiling? Competitive bid? How much risk can the organization tolerate with each estimation? Understanding this context, typically through fluid communication with the organization’s business side, is vital. Understand what game you are playing when entering the estimation exercise!
Should the estimations be done in a vacuum without introducing any bias in the engineers doing them? Maybe in a first iteration, but then ideally, a two-way conversation or negotiation should occur between what’s expected, typically framed by the business side, and what’s realistically possible, according to the engineering team.
Gathering Scope and Requirements
Obtaining accurate scope and requirements is crucial for a successful estimation. Get all the information available about requirements, both functional and non-functional. Make sure you get briefed and read whatever documentation available there is.
The name of this game is good communication. When essential information is lacking, raise your hand and relay that to the appropriate stakeholder (typically sales, product owner, or client), so they have a chance to evacuate any doubts.
Maybe a business analyst already went through the process of defining a tech specification, or maybe you need to play that role. Bridging needs and wants into more coherent technical requirements before diving into the estimation. If this is the case, you may need to schedule meetings to walk through the hazy aspects of the requirements.
Ask the right questions to optimize the disambiguation of requirements. If templates or checklists are available in the organization, capturing experience, use them. Go through them, and make sure all the critical information has been gathered.
Make Assumptions
Few things are certain. Among them: is knowing that there will be gaps in the information available. There will be uncertainty involved. In some cases, the gaps may be too big and the uncertainty too high, but even then, because of reasons (usually business reasons), your hand may be forced to come up with an estimation. This may be sugarcoated with phrases such as: “don’t worry, this is of no consequence, it just to have a rough idea” [Narrator´s voice: “This was a lie. It would determine the budget for the whole project”].
On the other hand, in defense of impatient sales reps, there’s value in not forcing the customer to spec every little detail to get the estimation out of the door. If a client says he needs, for instance, “a wheel,” then being acquainted with the standard business practice of what typically represents “a wheel” saves a lot of back and forth in communications and time for everyone involved.
In these scenarios, which are most where you need to fill in the gaps, do make assumptions. Be explicit about them. Scope what “a wheel” means in the context of your estimation, what it includes, and, equally importantly, what it won’t. Just don’t get analysis paralysis.
Assumptions should be provided along the effort estimation, as metadata is required to give context to the estimation exercise. This should be documented as clearly as possible, not in some hidden excel cell comment.
The Dual Nature of Estimation
Estimating effort is also about setting and managing expectations for all sides of the equation (customer, team, management).
It’s not the same to be told to build “a wheel” as to be told to build “a wheel” in X amount of hours using Y set of materials. The latter scenario forces the universe of possible options to collapse into the ones whose quality and characteristics match the available resources.
In this sense, effort estimation serves a dual purpose—it describes the anticipated work involved and prescribes a framework for how the project will unfold. It’s essential to be aware Engineers must strike a balance between creativity and practicality, ensuring they deliver the desired product within the allotted time and budget.
Once again, it is vital to document and communicate in a clear fashion the projected scenario of what will be possible given the existing constraints to avoid disappointments. For instance, being clear about what type of “wheel” the estimation is envisioning will be vital to avoid issues when it’s expected to perform under a specific load.
Effort Estimation Technique
This section will discuss various effort estimation techniques, including WBS, top-down, bottom-up, analogous, three-point, PERT, parametric, and Agile approaches.
Work Breakdown Structure (WBS)
A Work Breakdown Structure (WBS) is a hierarchical representation of a project’s various tasks and subtasks. By breaking down tasks into smaller, manageable pieces in a tree-like structure, engineers can more effectively assess the time and resources required to complete each task in a project.
Each level of the WBS represents a further breakdown of the project’s deliverables or objectives. The WBS enables project teams to identify and understand the relationships between different tasks, estimate the effort required for each task, and monitor progress throughout the project lifecycle.
The following is the WBS for a straightforward Company Picnic project.
| Level 1 | Level 2 | Level 3 |
|---|---|---|
| Company Picnic | Venue Selection | Research Possible Locations |
| Book Venue | ||
| Food Arrangements | Choose Menu | |
| Order Food | ||
| Activities | Plan Games | |
| Arrange Equipment | ||
| Invitations | Create Invitations List | |
| Send Invitations |
Top-down
This technique involves starting from high-level constraints, such as time and team size, and breaking down the work into smaller stages and components to fit these constraints. By considering the overall scope and resource limitations, top-down estimation allows project managers to allocate resources efficiently and manage expectations effectively.
Bottom-up
In contrast to top-down estimation, the bottom-up approach breaks down the work into more granular modules and tasks using a tree-like structure called the Work Breakdown Structure (WBS). Effort is estimated for each task (the leaves of the tree), and the total effort is calculated by summing up the estimates for all tasks. One downside of this method is the potential to overlook auxiliary or logistical tasks.
Analogous
This technique relies on past experiences and historical data from projects with similar characteristics. Project managers can make informed estimations for the current project by extrapolating the effort required for comparable projects.
Three-point
For each task, three values are estimated, representing the most optimistic, pessimistic, and likely scenarios. These values are then aggregated into an average per work package or module, providing a range of possible effort estimates.
PERT (Program Evaluation and Review Technique)
Like three-point estimation, PERT uses a weighted average, where the likely estimate carries more weight than the optimistic and pessimistic estimates.
Parametric
This technique involves breaking down the project structure into known building blocks and estimating the effort for each block type. For example, a software project could be divided into: Views, Endpoints, and CRUDs (Create, Read, Update, and Delete) with varying complexities. The total effort is then calculated by multiplying the estimated effort for each building block by the number of occurrences in the project.
Agile Techniques
Agile methodologies offer several effort estimation techniques, including:
- a. Planning Poker: Team members use cards representing effort levels to estimate tasks collaboratively, promoting team consensus and reducing estimation biases.
- b. T-shirt Sizes: Tasks are categorized into t-shirt sizes (e.g., small, medium, large) as a simple way to represent their relative effort.
- c. Fibonacci Sequence for Story Point Estimation: The Fibonacci sequence assigns story points, reflecting the increasing uncertainty associated with estimating larger tasks.
Selecting the most appropriate effort estimation technique depends on project size, complexity, and available historical data.
Best Practices in Effort Estimation
Assigning Hour Values to Tasks
Assigning discrete hour values to tasks (1, 4, 8, 16, 24) helps maintain consistency in estimates. If a task requires more than say … 40 hours, it may need to be broken down further to ensure accurate estimation.
Finding the Right Balance
Engineers should aim for a middle ground when estimating, avoiding overly optimistic or pessimistic assumptions. Striking a balance between best and worst-case scenarios leads to more realistic expectations and better project outcomes.
Accounting for all phases, roles, and types of tasks
Make sure in your effort estimation to consider all stages in a project lifecycle, such as setup, stabilization, and publishing. Roles beyond development include business analysts, project managers, developers, designers, quality assurance, and other specialists. And support tasks such as review of PRs, writing unit tests, creating builds, publishing, etc.
Combining Bottom-Up and Top-Down Approaches
A combination of bottom-up and top-down approaches provides a more comprehensive estimation. While the bottom-up approach focuses on detailed task estimation, the top-down approach considers calendar-based timeframes to ensure alignment with project deadlines.
The more, the merrier
When possible, involve multiple experts in the estimation process. This collaborative approach leads to a more accurate and well-rounded estimation curve, accounting for potential blind spots and uncertainties.
Using Historical Data
Leveraging historical data from past projects can significantly improve effort estimation accuracy. Cross-referencing previous experiences helps identify trends and patterns that can inform the current project’s estimates.
Be ready to justify your estimation
It’s common for estimations to be shared with the interested parties and for review rounds to take place where each item in the estimation is analyzed. If you participate in the estimation process, keep notes of your thought process. They may come in handy when you justify your estimation for a task.
Leveraging AI
A new generation of AI tools, including Large Language Models like ChatGPT, is emerging to revolutionize various aspects of software development. At the time of writing this article, these tools can assist in creating a Work Breakdown Structure (WBS) based on a project’s requirements. Moreover, AI can also aid in estimating the hours required for project completion, streamlining the overall estimation process.
Conclusion
Effort estimation is a crucial skill for engineers working on software projects. By adopting best practices, understanding the project’s context, and collaborating with experts and stakeholders, engineers can provide accurate estimates contributing to project success and client satisfaction.
I hope this essay may have brought your attention to some of the challenges and standard practices required when approaching this discipline, ultimately equipping you with the necessary knowledge and insight to do well in this critical and often underestimated task.
