Software Effort Estimation: How to Get It Right the First Time
Mục lục bài viết
1. Overview
Picture this: you’re a software developer working on a project and must estimate how long a particular task or feature will take. You start to think about all the variables that could affect the outcome: changes in the project scope, unexpected bugs, team dynamics, and more. It’s daunting, but ensuring the project stays on budget and schedule is essential.
Unfortunately, unreliable estimation is a top reason why IT projects fail. Misaligned budgets and schedules can throw the entire project off course, leading to frustration, missed deadlines, and even failure. But don’t worry; there’s hope!
With the right processes and estimation techniques, achieving accurate and consistent estimations is possible, making proper project planning feasible. One technique that has been gaining popularity is Agile story points. This relative estimation unit allows developers to estimate the size and complexity of user stories and features, making it easier to adapt to changing project requirements.
In this article, we’ll explore the challenges of software effort estimation, the importance of reliable estimation, and powerful techniques like Agile story points and Planning Poker. We’ll also provide a working formula for implementation to help you achieve the best results. So buckle up and get ready to learn all about software effort estimation!
2. What Is Software Estimation
Software estimation is the process of estimating the time, effort, and resources required to complete a software project or specific tasks within it. It is a crucial step in project planning, as accurate estimation helps avoid schedule and budget misalignments that can lead to project failure.
Software estimation is the process of estimating the time and resources required to complete a specific task. The figure above shows five of the most common techniques used to predict the estimations.
Software estimation is challenging, given the ever-changing nature of software development. However, developers use several techniques to achieve reliable and consistent estimations. Here are some of the main techniques:
Each technique has advantages and disadvantages, and the choice of technique often depends on the specific project requirements and the team’s expertise.
3. Why Is Estimating Software Important
Here are some advantages to getting the estimations right.
The benefits of accurate software estimations include a positive impact on budget and schedule, adequate risk management, proper communication, improved resource allocation and other advantages.
3.1 Impact on Budget and Schedule
Accurate software estimation helps budget planning, enabling businesses to allocate resources, make informed decisions, and avoid financial losses.
Estimation is also crucial in schedule planning. Without reliable estimations, project managers may set unrealistic timelines, leading to missed deadlines, ultimately resulting in project failure.
In Agile and Waterfall project management methodologies, effort estimates are crucial to project planning and management. Here’s how they are utilized:
Both methodologies use effort estimates to manage project scope, timeline, and budget. By estimating the effort required for each task, project managers can allocate resources effectively, plan the project schedule, and adjust the project plan as necessary.
3.2 Risk Management
Accurate estimation helps identify potential risks and challenges during software development. Project managers can then plan and allocate resources to mitigate such risks and ensure the project’s success.
3.3 Communication
Estimation also plays a vital role in communication between developers and project managers. Accurate estimations help developers to communicate the expected timeline and workload to project managers, leading to improved collaboration and better decision-making.
3.4 Resource Allocation
Estimation helps allocate resources, including human resources, equipment, and software tools. Knowing the effort required for each task helps distribute workloads equitably and ensures developers have the necessary resources to complete tasks within the scheduled timeline.
Organizations, including customers, typically operate under strict budgets. New projects that require additional resources or external consultants pose more risks. If such a project runs out of funds, its resources might become available, and if no one is available to execute it, it will be abandoned.
It is common for customers, particularly large ones, to have several concurrent projects, making it crucial to deliver on time to avoid jeopardizing other projects.
3.5 Improving Team Morale
Maintaining high morale is critical for achieving optimal performance and preserving the long-term mental well-being of any human group, including software development teams.
Setting unrealistic deadlines can increase stress levels, negatively impacting morale and confidence. This effect can be especially detrimental when such deadlines become common occurrences instead of isolated incidents.
Incorporating the development team in the effort estimation process can produce a positive outcome. Allowing team members to participate in determining the required effort for their respective tasks gives them a sense of ownership and accountability, resulting in a fair and just approach.
3.6 Managing Stakeholder Expectations
Accurate estimation is pivotal in effectively managing stakeholder expectations and ensuring a successful implementation. However, IT projects are inherently complex, making meeting the project’s schedule and budget constraints challenging.
Even though stakeholders understand the intricacies of completing IT projects, they still expect the supplier to deliver the project within the stipulated time and budget. The supplier is expected to put in their best efforts to achieve project objectives, as stakeholders are not likely to provide an unlimited budget or time.
3.7 Product Quality and Technical Debt
There are ample opportunities to enhance processes in any software development life cycle (SDLC) phase, including the Analysis stage, particularly the effort estimation component.
Effort estimates have a substantial impact on the quality of deliverables downstream. Consider the familiar scenario of projects that run out of time and the typical trade-offs made to meet pressing deadlines:
4. Why Is Software Estimation Hard
Estimates are difficult to calculate because of the uncertainty usually involved in complex systems like IT solutions, IT environments, and human groups. These uncertainties typically fall into two groups: known unknowns and unknown unknowns.
The challenge with software estimation is compounded by its immediate effect on the budget, schedule, and resource allocation.
Examples of known unknowns are:
- Periodically updated industry regulations
- Legacy code
- Poor processes or outdated delivery methodologies
- Changes in organisational strategy and priorities
- Natural disasters
- Loss of talent.
Unknown unknowns are more difficult (if not impossible) to anticipate; examples can be:
- Changing business requirements as a result of users interacting with the software
- Changing user preferences
- Novel technologies where users have yet to understand what the technology can do for them.
Agile and DevOps methodologies incorporate certain mechanisms, such as frequent releases and automated testing, to mitigate some of the abovementioned risks. Nevertheless, uncertainties arising from flawed processes can only be mitigated through proper process management, governance, and continual improvement.
Furthermore, accurately estimating effort in software development projects is complicated because each project is unique. Novelty can manifest in various forms, including innovative features, changing customer preferences, and new or emerging technology. This dynamic nature of software development renders expert judgement and statistical analysis less effective in producing reliable estimates.
5. The Cone of Uncertainty
You will usually never know how much effort a task needs until it’s almost done. Naturally, you can always provide a bracket wide enough to be accurate. For example, 1-10 years is a very accurate estimation for building a web application, but it is not very useful. You need precision, where a more precise and helpful answer to the previous question would be 8-12 months.
The cone of uncertainty is a graphical depiction oh uncertainty as a measure of implementation progress.
The cone of uncertainty is a graphical representation of the level of uncertainty in estimating a software project’s scope, schedule, and cost at different stages of the project’s life cycle. The cone represents the range of uncertainty in the estimates, and as the project progresses, the range narrows. The cone of uncertainty highlights the importance of accurate estimation in the early stages of a project and the need for regular re-estimation as the project progresses. It is a concept used in project management and software development to manage risk and avoid cost overruns and schedule delays.
At project inception, the estimation variance is highest, except that, at this stage, you need the highest precision you can hope for. Variance drops to zero after go-live and when the feature is already in production.
6. Estimation Challenges
Several reasons make estimation hard, including:
Addressing these challenges requires careful planning, robust estimation techniques, and continuous refinement of the estimation process.
7. Reliability of Software Estimation Techniques
Several techniques are commonly used in the industry for estimating software. They broadly fall under three categories:
- Top-to-Bottom approach — This method relies on expert judgement. It is probably the most unreliable as it doesn’t involve the technical staff executing the tasks and may not consider the specific capabilities of each individual.
- Bottom-Up approach — This is the most reliable and accurate of the lot. However, it requires more effort since technical staff will be needed to estimate their tasks. It also requires changes to be broken down into small pieces, requiring some effort.
- Statistical methods — This approach looks at historical data and calculates estimates based on averages and variances. This method is cumbersome and error-prone when historical data is sparse or biased (see Thoughts on Six Sigma for Software Development).
The below figure shows the reliability of the different methods.
The reliability of software estimation techniques varies from one method to another and depends on the size of the estimated piece and the availability of historical data.
8. Estimations in Waterfall
The Waterfall software estimation technique lists all the significant tasks in a project and breaks them into smaller pieces for easier management. Afterwards, an estimate is provided for each task in person days.
A critical path is then identified.
Critical Path Analysis
The critical path method (CPM) is a project modelling technique developed in the late 1950s where a critical path is defined as the shortest possible time the project needs from start to finish.
The critical path is delicate, and any delay in tasks on the critical path will eventually delay the whole project.
Project managers usually put significant effort into getting the estimates right to mitigate such risks. This emphasis on correct estimation helps assimilate potential delays and makes the critical path more resilient.
9. Estimations in Agile
9.1 Overview
Estimating software effort in Agile works somehow differently. Like Waterfall, Agile also breaks big chunks of work into Epics, User Stories, and Tasks, but Agile uses story points instead of person-days.
One of the fundamental concepts of Agile is accepting uncertainty and changing requirements, even late in the project.
This concept makes effort estimation in a precise number of days inherently tricky as it shifts the effort from planning and design into faster, more frequent deliveries. Both planning and meticulous design are prerequisites for better estimations.
Story points are more flexible in that A) there is no rigid equivalency between story points and person-days (this is dynamically calculated per team and project and constantly updated throughout the implementation), and B) as the estimates grow, so does the safety margin in the story points (ensured by using a Fibonacci series).
Story points, however, have their problems, and so does the entire estimation process in Agile.
With Agile, you lock the requirements but loosen the schedule; if a feature is not completed in this sprint, it will be finished in the next. This trade-off makes the need for estimations for project planning questionable.
9.2 Agile Story Points and Their Meaning
Agile story points are a unit of measure used to estimate the size and complexity of user stories and feature in Agile development. Unlike traditional estimation units like hours or days, Agile story points are relative and abstract, based on the team’s collective understanding of what constitutes a small, medium, or large user story or feature.
The main benefit of using Agile story points is that they allow teams to estimate the effort needed for a particular task or feature without committing to a specific amount of time. This flexibility makes it easier to adapt to project scope or requirements changes.
To use Agile story points effectively, teams must establish a common understanding of what each point value means. This can be done using a reference story or a baseline to establish a benchmark for different point values. For example, a team might agree that a one-point story represents a simple task that can be completed in a few hours, while a five-point story represents a complex feature that will take several weeks to complete.
9.3 Story Point Sizing
Sizing user stories using Agile story points involves breaking each story into smaller tasks or sub-stories and assigning a point value. The team then adds the point values of all the sub-stories to get the total point value for the user story.
When sizing user stories, it’s important to consider factors like complexity, uncertainty, and dependencies. For example, a user story requiring integration with a third-party API might be more complex than one without. Similarly, a user story that depends on another user story being completed first might have more uncertainty.
To account for these factors, teams can use techniques like Planning Poker, which we’ll discuss in more detail later.
9.4 Story Points Agile to Hours
While Agile story points are useful for estimating the size and complexity of user stories and features, they are not intended to be a direct measure of time. However, estimating how long a particular task or feature will take to complete is often useful.
One way to convert story points to hours is to use the team’s velocity, the average number of story points the team can complete in a given sprint. To calculate velocity, simply add the story points of all the completed user stories in a sprint and divide them by the number of sprints.
Once you have the team’s velocity, you can estimate the effort needed for a particular task or feature by dividing the total story points by the team’s velocity. For example, if a task has an estimated size of 10 story points and the team’s velocity is 20 story points per sprint, the task would be estimated to take 0.5 sprints or roughly 2 weeks.
It’s important to note that converting story points to hours should be done cautiously, as it can lead to overestimation or underestimation of the actual effort needed. In general, it’s better to focus on the relative size and complexity of user stories and features rather than trying to convert them to a specific amount of time.
9.5 Planning Poker
Planning Poker is a popular technique for estimating user stories using Agile story points. The technique involves the following steps:
- The product owner or Scrum master presents a user story to the team.
- The team discusses the user story and asks any questions they have to clarify the requirements.
- Each team member privately selects a card with a point value that they believe represents the size and complexity of the user story. The cards typically range from 0 to 100, with the most common point values being 1, 2, 3, 5, 8, 13, 20, 40, and 100.
- The cards are revealed simultaneously, and any differences in point values are discussed. The team members who selected the highest and lowest point values explain their reasoning.
- The team repeats the process until a consensus is reached on the point value of the user story.
Planning Poker encourages collaboration and discussion among team members and helps to ensure that everyone has a shared understanding of the user story’s size and complexity.
10. Step-by-Step Guide to Better Software Estimation
We propose the following software estimation technique. Its main advantage is its structured approach, while its weakness is that it’s limited to Hybrid software delivery models.
This limitation, however, is not overwhelming from a practical perspective. This is due to the popularity of the Hybrid model vis-a-vis Agile or Waterfall on the one hand and the fact that software estimation is not as critical with pure DevOps or Agile.
The diagram below shows the different steps involved in the estimation process.
The software estimation process proposed consists of two major stages: a high-level estimation stage and a low-level one.
Step 1: Requirement Definition
The first step in any software estimation process is to define the project’s requirements. This includes gathering information about the customer’s needs, the problem the software will solve, the required features, and any constraints or limitations.
Step 2: Epic Definition and High-Level Design
Once the requirements are defined, the next step is to break down the features into smaller, more manageable pieces. This is typically done by creating epics and high-level descriptions of functionality. Once the epics are created, a high-level design is created to determine how the features will be implemented.
Step 3: Generate a Rough Order of Magnitude
The next step in the estimation process is to estimate the effort required to complete the features. This is typically done using techniques like T-Shirt sizing or Rough Order of Magnitude. T-Shirt sizing involves estimating the effort required for each feature using a t-shirt size (e.g. small, medium, large). In contrast, Rough Order of Magnitude involves providing a high-level estimate of the effort required based on previous similar projects.
Step 4: Scoping
The final step in the estimation process is to scope the project and sort the backlog. Scoping involves determining the project’s boundaries, what features will be included, and what will not be included. Backlog sorting involves prioritizing the features based on their importance and the effort required to complete them. This helps to ensure that the most critical features are completed first and the project stays on track.
Step 5: Low-Level Design
This is the stage where the technical requirements of the software are defined in detail. It includes defining the data models, software architecture, and implementation approach.
Step 6: User Story Definition
User stories describe a feature or functionality from the perspective of an end-user. They typically follow a “As a [user], I want [action], so that [outcome]” format. User stories can help break down the software requirements into manageable pieces and help ensure that the software meets the needs of the end users.
Step 7: Story Point-Based Estimation
Story points are a relative measure of the complexity and effort required to implement a user story. Story points are typically assigned based on a team’s experience and knowledge of the technology stack.
Story points are a more abstract measure than time-based estimates, which can be more accurate but more difficult to estimate. Using story points, teams can estimate the effort required for a user story without worrying about specific timeframes.
Step 8: Detailed Planning
Once the user stories have been estimated in story points, the team can create a detailed plan. The plan should include a breakdown of the user stories into tasks and subtasks and the estimated effort required for each task. The plan should also consider any dependencies between tasks and the team’s capacity to deliver work within a given timeframe.
11. Heuristics for Story Point Estimation
Is story point-based estimation advantageous over the classical person-day approach? If developers can provide better estimates in one scale (Fibonacci series) and a linear mapping exists between that scale (story points) and working hours, surely both approaches can be considered identical?
This author’s experience says that accurate and precise estimations are equally challenging regardless of which scale is used, and that is exactly due to the above-mentioned reason. If you can predict difficulties and future uncertainties, you can surely and promptly map these into story points, hours or days. The bottom line is that estimation is difficult, and developers can benefit from heuristics to aid them through the process.
One heuristic that I found useful was creating static definitions of the different complexity levels that can be anticipated. These definitions are not universal and will depend heavily on the software application, the team’s capabilities, and the context in which the team operates.
The below table provides an example of such a definition.
Story PointLevelCategory Description1MinorSmall configuration change or document update.2Very EasyMinor code updates, such as cosmetic changes.3EasyExtending an existing feature, like adding a new parameter.5AverageAdditional or modification of major components, such as a web page, user report, or major configuration changes.8DifficultRequiring more expertise or time. Example: modifying core components or implementing complicated business logic where industry expertise is required.13Very DifficultRefactoring large code units and redesigning existing features.21Extremely DifficultAdding core components, supporting additional platforms, new interfaces…Story point category definition
The advantages of having such guidelines are numerous and can be summarized as follows:
- It provides a baseline for expert judgment to anchor on.
- It prompts the developers to consider all aspects of a development task.
- It invites discussions based on tangible ideas.
12. FAQ
Software effort estimation predicts the time and resources required to complete a software development project. It involves using historical data, industry knowledge, and statistical analysis to estimate the time and resources needed for a project.
Software effort estimation is important because it helps software development teams plan and manage their projects effectively. Accurate effort estimation can help teams allocate resources and manage timelines, which is critical for project success. Without accurate estimates, development projects can become delayed, over budget, or fail to meet client expectations.
Some common challenges in software effort estimation include uncertainty in project scope, lack of historical data, and differences in skill levels among team members. Additionally, unforeseen technical issues or changes in requirements can also impact the accuracy of software effort estimation.
Software effort estimation challenges can be overcome by following established best practices and using proven estimation techniques. Gathering as much information as possible about the project requirements and historical data is important to make informed estimates. Regular communication among team members can also help identify potential issues or changes impacting the estimation process.
Several factors can impact the accuracy of software effort estimation, including project scope, team skill levels, historical data availability, and project complexity. Other factors, such as changing requirements, technical issues, and external dependencies, can also affect effort estimation accuracy.
Software development teams can improve their ability to estimate software development efforts by adopting established best practices and techniques. This includes using historical data, breaking down tasks into smaller components, involving team members with relevant expertise, and regularly revising estimates as new information becomes available.
Popular software estimation techniques in software development projects include Function Points, Use Case Points, Wideband Delphi, and the Three-Point Estimation Technique. These techniques involve using historical data and statistical analysis to predict project timelines and resource needs.
Software estimation techniques differ in terms of the variables they consider, the level of detail they provide, and the level of statistical analysis involved. Some techniques, like Function Points and Use Case Points, focus on quantifying software functionality. Others, like the Three Point Estimation Technique, consider multiple variables and probabilities to provide a range of possible outcomes.
Software estimation can be integrated into software development by establishing clear guidelines and involving all relevant team members. This can help ensure that estimates are accurate and reflect the collective knowledge and expertise of the team. Regularly revising estimates as new information becomes available can also help improve project planning and management.
13. Final Words
Accurate software effort estimation is essential to the success of any project. It sends a clear message of professionalism, instilling confidence and optimism in clients and stakeholders. Proper estimations make collaboration smoother and project management more effective, leading to better deliveries and more efficient performance.
While the proposed guide may not be popular with project managers and senior management, it is a valuable tool for complex systems and an important departure from traditional estimation techniques. However, like any production process, good governance must remain ahead of the curve. This includes monitoring, updating, and validating the estimation process to ensure accuracy and effectiveness.
By implementing a reliable estimation process and continually improving it, organizations can increase their chances of delivering projects on time, within budget, and with the desired level of quality.
14. Further References
Great talk by Bob Martin on the subject.
