Estimation in project management is the starting point for the formation of schedules, allocation of resources and making decisions. Accurate estimates inform stakeholders of what they can expect, enable the optimum use of resources and guarantee the delivery of outputs on schedule. Despite this, there are challenges in meeting particular targets in software projects that necessitate the most accurate forecasting of requirements considering the nature of the project as volatile and having uncertainties during implementation. This blog describes contemporary estimation practices designed for software projects, compares these with previous ones, and describes how they can be used in practice.
In the previous article we looked at 'Managing Large IT Programs | Project Planning & Activities List'. In this article, we will explore Project Estimation Techniques through below sections:
Traditional Estimation Techniques
Traditional project management methods rely on structured approaches that often assume a well-defined scope and minimal uncertainties. These methods include breaking down tasks, leveraging historical data, and applying mathematical models to project effort and timelines.
Here are some commonly used techniques:
Bottom-Up Estimation
Definition: Breaking a project into smaller, manageable tasks, estimating each task individually, and summing them up to get the total effort.
When to Use: Works well when all project details are known upfront.
Example:
A project to develop a website is divided into tasks: designing the UI (10 hours), coding (20 hours), testing (15 hours), and deployment (5 hours).
Total estimate = 50 hours.
Parametric Estimating
Definition: Using statistical relationships between historical data and project variables to predict effort or cost.
When to Use: Effective when historical data is available and the task's complexity is understood.
Example:
If developing 1 page of a website takes 5 hours, and the project involves 10 pages, the total estimate is 10 x 5 = 50 hours.
Analogous Estimating
Definition: Using estimates from similar, past projects as a reference for the current project.
When to Use: Ideal for early-stage planning when detailed information is lacking.
Example:
If a previous e-commerce website with comparable features took 400 hours to complete, the current project might be estimated to require a similar amount of effort.
Gantt Charts and Work Breakdown Structures (WBS)
Definition:
WBS: Hierarchical decomposition of the project into smaller deliverables.
Gantt Chart: A visual timeline showing task schedules, dependencies, and progress.
When to Use: Suitable for traditional projects with sequential workflows and interdependent tasks.
Example:
A WBS for a software project might include phases like "Requirements Gathering," "Development," "Testing," and "Deployment."
A Gantt Chart illustrates these phases with timelines and dependencies, such as "Testing cannot begin until Development is complete."
Program Evaluation and Review Technique (PERT)
Definition: A probabilistic technique that calculates a weighted average estimate using three scenarios:
Optimistic (O): Best-case estimate with minimal risks.
Pessimistic (P): Worst-case estimate considering all risks.
Most Likely (M): The estimate assuming normal conditions.
Formula: PERT Estimate
When to Use: Suitable for projects with uncertainty or tasks that require expert judgment.
Example:
Task: Develop a new feature.
Optimistic (O): 3 days.
Most Likely (M): 5 days.
Pessimistic (P): 9 days.
PERT Estimate:
These traditional estimation techniques provide structured ways to predict effort and timelines but may struggle with the unpredictability and dynamic scope of software projects. For such scenarios, modern techniques like Agile Estimation become more relevant.
Limitations in Software Projects
Software projects, by nature, are dynamic and complex, posing several challenges to traditional estimation methods:
Dynamic Requirements: Constantly changing user needs and business priorities make initial estimates quickly obsolete.
Scope Creep: Unforeseen additions to scope can derail estimates.
High Uncertainty: Software development involves creative problem-solving, where unknowns often emerge.
Difficulty in Quantifying Effort: Intangible factors, like debugging complexity or integration challenges, are hard to measure accurately.
These limitations necessitate a shift to more adaptive and flexible estimation techniques.
Softwate & Digital Product Estimation Techniques
Absolute vs. Relative Estimation
Modern estimation methods in software projects emphasize adaptability. Two primary paradigms are:
Absolute Estimation: Assigning exact numbers, like hours or days, to tasks.
Example: Estimating a coding task as "16 hours."
Drawback: Inaccuracy due to overconfidence or insufficient understanding.
Relative Estimation: Comparing tasks to each other in terms of size, complexity, or effort, without assigning absolute values.
Example: Task A is twice as complex as Task B.
Advantage: Helps manage uncertainty and provides flexibility in changing conditions.
Agile methodologies, such as Scrum, heavily favor relative estimation for its adaptability and team-centric approach.
Relative Estimation Techniques
Story Points
Definition: A unitless measure representing the relative effort required to complete a user story.
How It Works: Teams assign story points based on factors like complexity, risk, and volume of work.
Estimation Scale: Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or custom scales to reflect task differentiation.
Example: A login feature might be 3 story points, while a complex reporting module could be 8.
Calculation: Use historical velocity (points completed per sprint) to project timelines for new tasks.
T-Shirt Sizing
Definition: Categorizing tasks into predefined sizes—XS, S, M, L, XL—based on effort or complexity.
How It Works:
Size tasks relatively without overthinking numerical values.
Convert sizes to story points when required (e.g., XS = 1, S = 3, etc.).
Example: A login page might be "S," while a full reporting module might be "L."
Ideal Days
Definition: Estimating the time required to complete a task if working without interruptions.
How It Works:
Assumes a perfect work environment.
Adjusts later to account for distractions, dependencies, and overhead.
Example: Writing a simple API might take 2 ideal days, but in real-world conditions, it might span 4 actual days due to meetings and other distractions.
What is Planning Poker?
Planning Poker, also known as Scrum Poker, is a consensus-driven estimation technique widely used in Agile teams. It combines expert judgment and team collaboration to assign story points to user stories. The method is particularly effective in ensuring diverse perspectives and minimizing biases during estimation.
How Planning Poker Works:
Preparation:
The Product Owner presents a user story to the team, detailing requirements and acceptance criteria.
Individual Estimation:
Each team member uses a deck of cards (with values like 1, 2, 3, 5, 8, 13, etc., often Fibonacci-based) to estimate the story's complexity.
Members choose a card privately and reveal them simultaneously.
Discussion and Consensus:
If estimates differ significantly, team members discuss their reasoning, focusing on complexity, risks, and uncertainties.
The process is repeated until the team reaches a consensus on the story points.
Outcome:
The agreed-upon story point value is recorded for the user story.
Example:
A team is estimating the "Add to Cart" functionality.
Member A selects 5 points, citing moderate complexity in backend integration.
Member B selects 8 points, highlighting potential risks with scalability.
Member C selects 3 points, noting that similar functionality was implemented before.
After discussion, the team agrees on 5 points based on shared understanding and clarification.
Planning Poker fosters team collaboration, highlights potential challenges early, and ensures a balanced approach to estimation.
Fist of Five Estimation Technique
What is Fist of Five?
Fist of Five is a simple and quick consensus-building technique often used for estimating effort or assessing agreement within Agile teams. It allows team members to express their level of confidence or alignment with an estimate using their fingers.
How It Works:
The Product Owner or Scrum Master presents a user story or task to the team, along with its context and requirements.
Each team member simultaneously shows a number of fingers (1 to 5) to indicate their opinion:
5 fingers: Fully agree; the estimate is spot-on.
4 fingers: Mostly agree; minor reservations.
3 fingers: Neutral; neither agree nor disagree.
2 fingers: Disagree; concerns need discussion.
1 finger: Strongly disagree; major issues need resolution.
The team discusses discrepancies in votes, particularly from those showing fewer fingers, and works toward alignment.
Example:
Task: Estimate effort for creating a "Profile Management" feature.
Team members raise their hands:
Member A shows 5 fingers (fully confident the task fits within current knowledge).
Member B shows 3 fingers (neutral, uncertain about edge cases).
Member C shows 2 fingers (concerned about integration with an external API).
Discussion:
Member C explains the API integration risk, and the team agrees to research further.
After clarifying unknowns, the team re-votes, and consensus shifts to 4 fingers overall.
Why Use Fist of Five?
It fosters transparency and encourages everyone to voice their opinions.
It's quick and ensures team alignment on estimates before moving forward.
Project Estimation Techniques Example: Planning a New Feature – Online Shopping Cart
Context: Your team is tasked with delivering an online shopping cart feature. The work includes:
Login/Authentication System
Add to Cart Functionality
Cart Summary Page
Checkout Process with Payment Integration
Using Story Points
Team Discussion: The team assesses each task based on complexity, effort, and risk.
Assignment of Story Points:
Login/Authentication: 3 points (straightforward implementation).
Add to Cart: 5 points (slightly more complex due to backend work).
Cart Summary Page: 8 points (requires integration and UI).
Checkout Process: 13 points (high complexity with external payment gateway).
Sprint Planning:
The team’s historical velocity is 20 points per sprint.
Total points = 3 + 5 + 8 + 13 = 29 points.
The feature will take roughly 2 sprints (20 points in the first sprint, remaining 9 in the next).
Using T-Shirt Sizing
Initial Size Allocation:
Login/Authentication: S
Add to Cart: M
Cart Summary Page: L
Checkout Process: XL
Converting Sizes to Story Points:
S = 3, M = 5, L = 8, XL = 13 (mapped using Fibonacci scale).
Result: Same story points as above.
Adjustment:
Tasks sized as "XS" or "S" might be bundled together for quicker delivery.
Using Ideal Days
Ideal Day Estimates:
Login/Authentication: 1 day.
Add to Cart: 2 days.
Cart Summary Page: 3 days.
Checkout Process: 5 days.
Adjusting for Reality:
Adding overheads (meetings, testing, code reviews, etc.), ideal estimates are multiplied by 1.5.
Revised estimates:
Login/Authentication: 1.5 days.
Add to Cart: 3 days.
Cart Summary Page: 4.5 days.
Checkout Process: 7.5 days.
Total Estimate: Approximately 16.5 actual days for the entire feature.
How to Estimate for Releases and Programs?
Release Planning
Using Velocity: Velocity, the average number of story points completed in a sprint, helps forecast delivery timelines.
Example: If a team completes 30 story points per sprint and a release backlog contains 120 points, the release will take four sprints.
Incorporating Buffers: Add time for potential risks and dependencies between teams.
Refer Agile Release Planning: A Comprehensive Guide for Project Managers for more details on release planning.
Program-Level Estimation
Rolling Up Estimates: Aggregate estimates from multiple teams to calculate program-level timelines.
Risk Management: Account for cross-team dependencies, technical risks, and potential delays.
Example: For a multi-team program involving 5 teams delivering 500 story points, use historical velocities to determine the total effort and add program-level buffers for alignment.
Accurate estimation for releases and programs requires balancing detailed task-level analysis with big-picture planning, along with constant refinement based on feedback and progress.
Estimating for a Release or a Program with Multiple Teams
Release-Level Planning
Backlog Preparation: Map all features for the release (e.g., shopping cart, user profile, order history).
Using Velocity:
Assume the team’s velocity is 20 points per sprint.
Total release backlog = 120 points.
Estimated duration = 6 sprints.
Buffer Inclusion:
Add 10-15% for risks and dependencies, making it 7 sprints total.
Program-Level Example (Multiple Teams)
Scenario: Five teams work on an e-commerce platform, with combined scope of 500 points.
Estimate Roll-Up:
Average velocity:
Team A: 20 points/sprint.
Team B: 25 points/sprint.
Teams C, D, E: 15 points each/sprint.
Total velocity = 90 points/sprint.
Program completion: 6 sprints (500 ÷ 90).
Account for Interdependencies:
Add a 10% buffer for integration and alignment.
Total program time: 7 sprints.
This structured example helps visualize how to apply different estimation techniques in practice.
Tips for Effective Estimation
Involve all the Members: An estimate can be carried out with the help of many people such as developers, testers, and other people. This is advantageous as it allows for a wide range of estimations and gives a more accurate estimate.
Reference Past Estimates: One can use some metrics from past sprints such as velocity or the number of tasks completed during a sprint to create new ones.
Decompose User Stories: Before making estimates, first break down big and complicated user stories, into smaller, simple tasks. This reduces the chances of ambiguity and increases probabilistic precision.
Consider their relative effort: Any time an estimation is done, it is important to make references to the effort estimations previously made for similar tasks, this maintains a constant effort estimation scale.
Always Address Risks: It is wise to include a risk buffer while estimating especially when dealing with new technologies or other unknowns.
Always Iterate: Estimation should be made as a phase of evolution, and if new information arises then it can be used to adjust the original estimation.
Aim Loose Instead of Tight: Estimation should not be taken too directly. This process should allow for a range of possibilities, which avoids making over the top precise predictions.
By following these tips, teams can increase their reliability of their estimates while also increasing delivery predictability.
Conclusion
Estimating can be seen as an art, a process that involves different skillsets, teamwork, and an evolutions over time. In my experience, estimating a software project is quite different as it often employs techniques like Aype, T-shirt sizing, and Planning Poker which alludes to best practices.
When a team collaborates effectively, considers past performance and employs the right estimating measures, they can enhance their estimating abilities consistently leading to more effective project implementation.
When estimating is done consistently, it creates a framework for execution that greatly impact release planning, team collaboration and management stakeholders expectations. However, there is no way to be 100% sure of the estimate, flexibility and other external factors are of great importance.
Common Interview questions on Project Estimation Techniques
What are the different estimation techniques you are familiar with, and when would you use each?
How would you estimate the effort required for a user story that has unclear or vague requirements?
Can you explain the difference between absolute and relative estimation? Which do you prefer and for what reasons?
How would you deal with the large variance in estimation of some of the members of the team during a Planning Poker session?
What is the role of historical data in estimation, and what is the use of previous sprint velocity for projecting the amount of work to be done in the future?
What is the PERT (Program Evaluation and Review Technique) method, and how would you use it in a software development project?
How do you estimate for large features or releases which require multiple teams to work for more than one or two sprints?
What steps would you take so as to progressively improve the accuracy of your team estimates over time?
Can you explain what the term "story points" means? How do you determine the story points that you give to a user story?
What do you do when the project scope or requirements are modified while the project is ongoing, and what is the impact of these modifications on your estimates?
Download the notes here:
Coming up in the next blog - 'Requirement Prioritisation Techniques'.
Note 1: This blog is part of a 100 Days of Learning Series on Digital Project Management frameworks and best practices published on Program Strategy HQ. For more details on the 100 days of blogging campaign check out Blog 0.
Note 2: Reach out to programstrategyhq@gmail.com for any queries.
Note 3: Program Strategy HQ Disclaimer for Reference.
Comments