When we talk about estimation , it's crucial to understand that we're not just quantifying time and scope as the most intuitive things. The multi-faceted nature of projects requires a broad spectrum of estimates, each serving a distinct purpose. Some of them are used in waterfall methods, some in Agile, but it is important to understand different methods and when they are used.
What can team estimate:
- Schedule Estimation: The staple of any project, estimating the duration outlines the overall project timeline as well as the timelines for individual tasks or phases with major milestones.
Where used:
In Waterfall schedule estimation is one of foundation stones. Team creates a complicated schedule for the project.
In Lean Six Sigma - team might have some estimation of DMAIC project, but it is less precise compare to the Waterfall.
Agile/Scrum - Team chooses sprint time and keep it during each cycle. Schedule estimations are not commonly used.
Example: For example, in the Waterfall methodology when we build a house, each phase has a clear beginning and end date, making schedule estimation critical for sequential progression and delivering materials and manpower.
- Budget Estimation: This revolves around the anticipated financial expenses of a project.
Where used:
In Waterfall budget estimation is second of foundation stones. Team creates a complicated budget for the project.
In Lean Six Sigma - before project is started team provides estimation of the project costs. They might be not precise.
Agile/Scrum - focus on estimating budgets for each sprint or release, aligning with the iterative nature of the methodology. Giving team manpower cost and additional expenses .
Example: For example, in the Waterfall methodology when we build a house, an upfront detailed budget estimation is a must, given its linear and phased nature. For instance, a company might allocate $100,000 for the foundation, $300,000 for 1st floor house construction, and so on.
- Workload (Scope) Estimation: Here, the focus is on the volume or magnitude of work, what should be done during the project
Where used:
In Waterfall, the scope is the third of foundation stones. Defined exhaustively at the outset, meaning the entire project's workload is estimated upfront. Project managers focused on performing initial work and any changes can be implemented using Change orders confirmed by all parties.
In Lean Six Sigma - before project is started team has problem statement that they plan to resolve. Methods are not defined and can change during DMAIC stages of the project.
In Agile/Scrum - Agile, scope is adaptive and always changing, revisits and re-estimates the scope as the project evolves, accommodating changes or new requirements that emerge. Team has their capacity how much work they can do in one cycle and they are trying to achieve maximum utilization of their resources.
Example: For instance, a software team might have description of feature and function they are required to develop in its initial documentation, but after team provides MVP to the customer, they requirements might change based on first feedback gathered.
- Resource Estimation: This pertains to the entirety of resources, be it human, technological, or material to successfully undertake and conclude a project.
Where used:
Waterfall: Resources, both human and technological, are identified comprehensively at the project's start. The method's sequential nature demands that every potential need is mapped out before the process gets underway. For example, before the development phase begins, the exact number of developers, software licenses, or servers that will be needed is pre-decided procurement/hiring stages are defined.
Lean Six Sigma: While the primary focus is on improving processes, the resources required for each DMAIC phase (Define, Measure, Analyze, Improve, Control) are identified in advance. Depending on the current phase, whether it's data collection in Measure or pilot testing in Improve, the necessary tools, team members, and technology are earmarked.
Agile/Scrum: The approach is iterative. Resources are usually estimated for the upcoming sprint, based on the tasks chosen from the backlog. A Scrum team would analyze the user stories for the next sprint and determine the necessary expertise, tools, and technology.
Example: Consider a mobile app project. In Waterfall, one might decide upfront they need three app developers, two UI/UX designers, specific software tools, and a particular server configuration. Meanwhile, in an Agile setup, depending on the user stories in the sprint, they might ascertain that two app developers and a UI designer are sufficient for the next two weeks.
- Risk Estimation: With every project comes uncertainties. Risk estimation is about foretelling potential challenges and formulating strategies to mitigate or manage them.
Where used:
Waterfall: Risks are anticipated during the initial planning stages. Comprehensive risk management plans and risk registers are then developed, including contingency plans for potential pitfalls. The assumption is that by anticipating all possible risks in advance, the project will run smoothly. Risk are prioritize using prioritizing matrix based on severity, frequency and traceability.
Lean Six Sigma: Risks are often associated with the changes proposed, especially during the Improve phase. As the methodology focuses on process improvement, risks related to deviating from existing processes are keenly examined.
Agile/Scrum: Risk management is an ongoing activity. Given its adaptive nature, Agile methodologies constantly revisit risks, making room for unexpected challenges. During sprint reviews or retrospectives, teams often discuss new risks and adjust their strategies.
Example: For a cloud migration project, a Waterfall approach might identify risks like data loss or downtime at the outset, setting up strategies and backups in advance. In an Agile approach, as teams migrate portions of data iteratively, they might encounter unanticipated issues like compatibility or integration challenges, which they then address in real-time.
- Quality Estimation: Quality estimation determines the efforts necessary to meet the desired standards of a deliverable.
Where used:
Waterfall: Quality assurance is pivotal. A distinct phase towards the project's conclusion ensures that the output aligns with the set standards. Benchmarks are established at the start, and the project's deliverables are matched against these during the quality assurance phase.
Lean Six Sigma: Quality is intrinsic to this methodology. Given its focus on process improvement, quality estimation revolves around gauging the improvements in process efficiency, reduction in errors, or enhancement in output quality across DMAIC stages. Quality metrics precisely calculated and planning used to make sure they are implemented after project is finished.
Agile/Scrum: Continuous quality checks are integral. Rather than a separate phase, quality assurance activities are embedded throughout the project lifecycle. Definition of Done and Acceptance criteria are used to make sure that every increment meet requirements. As each feature or user story is developed, it undergoes testing and validation to ensure it meets the acceptance criteria.
Example: In developing a new software, a Waterfall approach might involve a comprehensive testing phase after the development phase, ensuring every function works seamlessly. Conversely, in Agile, after developing a feature, it's immediately tested. If a chatbot feature is created, its responsiveness, accuracy, and efficiency are validated before moving to the next feature.
Most common estimate techniques:
1. Planning Poker
Planning Poker, also known as Scrum Poker, is a consensus-based technique employed by Agile teams to estimate the effort or relative size of user stories in a product backlog. It encourages team collaboration and avoids anchoring, where an individual's estimate influences others.
Where Used: Agile estimations.
Additional information: The card sequence recommended by Mountain Goat Software's Mike Cohn, who popularized planning poker for agile development, is 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. The decks are limited, with significant number-jumps, because the goal is for all participants to reach a consensus number for each story.
How It Works:
- Card Sets: Each participant is given a set of cards, each bearing a number. These numbers typically follow a sequence (often Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34, etc.). The higher the number, the more complex the task is perceived to be.
- Presenting the Task: The product owner or Scrum master presents a user story or task and provides a detailed explanation.
- Team Discussion: Team members discuss the requirements and nuances of the task but avoid mentioning any estimates at this stage.
- Estimation Round: After the discussion, each participant selects a card that represents their estimate for the effort required. Once everyone has chosen a card, all cards are revealed simultaneously.
- Discussion of Variances: If there's a large variance in estimates, the team discusses the reasons for their choices, especially the outliers. This step ensures that everyone has a clear understanding of the task at hand.
- Re-estimation: After the discussion, the team may choose to estimate again, repeating steps 3-5, until they arrive at a consensus.
- Consensus: The process continues until the team reaches a general agreement on the estimation of the task. The chosen estimate is then assigned to the user story.
Example: Developing a Login Feature
User Story: As a user, I want to be able to log into the web application so I can access my personalized dashboard.
During the discussion, developers might raise concerns about integrating different OAuth providers, while designers could talk about the need for a user-friendly interface.
Estimations:
- Developer A chooses 5, thinking about the backend complexities.
- Developer B selects 3, feeling they've done similar tasks before.
- Designer A picks 8, anticipating multiple design iterations.
- QA Engineer chooses 5, considering potential test scenarios.
Seeing the variance, the team discusses further and decides to go with a 5, balancing the perceived complexities and past experiences.
Benefits of Planning Poker:
- Avoids Anchoring: Since estimates are revealed simultaneously, team members aren't influenced by one another.
- Promotes Discussion: Varied estimates lead to discussions, ensuring a deeper understanding of tasks.
- Consensus-based: It values team input and fosters collaboration.
- Flexibility: It's adaptable, with teams able to modify the card sequences to suit their preferences.
2. Bucket System
The Bucket System is an agile estimation technique that, instead of using cards as in Planning Poker, employs buckets as the medium. These buckets represent predefined estimate ranges, and the aim is to categorize the user stories or tasks into these buckets based on the perceived effort required.
Where Used: Agile estimations.
Additional information: Usually used on early stages of project estimations and/or when there are many user stories need to be estimated, but estimations can be not so precise at the moment. Same as planning poker but less precise.
How It Works:
- Predefined Buckets: Set up multiple buckets, each representing a range of effort or size. This could be in the form of numeric ranges like "1-2, 3-5, 6-8" or any other suitable categorization.
- Presenting the Task: Similar to Planning Poker, the product owner or Scrum master introduces a user story or task and provides an in-depth explanation.
- Team Discussion: Team members converse about the requirements and details of the task, ensuring all aspects and complexities are understood.
- Estimation Round: Participants place the user story into a bucket that they believe best represents the effort required. If there's a disagreement, it leads to further discussion.
- Reaching Consensus: The team discusses until they agree upon which bucket the task fits into. Once a consensus is reached, the user story is assigned the value of that bucket.
Example: Implementing a Comment System
User Story: As a user, I want to be able to log into the web application so I can access my personalized dashboard.
During the discussion, developers might raise concerns about integrating different OAuth providers, while designers could talk about the need for a user-friendly interface.
Estimations:
- Developer A places it in the "3-5" bucket, considering the backend structure.
- Designer A thinks it's more "6-8", looking at the design intricacies.
- QA Engineer opts for "3-5", anticipating standard testing scenarios.
After discussions, the team agrees to place it in the "3-5" bucket, as they feel they've tackled similar features before.
Benefits of the Bucket System:
- Avoids Precise Numerical Anchoring: Instead of getting stuck on exact numbers, teams think in terms of broader effort ranges.
- Promotes Group Discussion: Different bucket choices lead to clarifications and deeper understanding.
- Rapid Estimations: Especially useful for large backlogs as it allows for quicker categorization.
- Flexibility: The bucket ranges can be adjusted to the team's comfort.
3. T-Shirt Sizes
T-Shirt Sizes is a relative estimation technique where tasks or user stories are categorized based on sizes typically found in clothing: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large), and so on. It's an abstract way of defining the scale of work, making it more intuitive and less anchored to numeric values that could be assigned later.
Where Used: Agile estimations; Waterfall, Agile and Lean six sigma prioritization matrixes.
Additional information: This is common during brainstorming and prioritization of functions. Often used by product managers when they work separately. Modifications of this techniques also often used when Risk Matrix is created.
How It Works:
- Defining Size Categories: The team sets up size categories, generally starting from XS to XL or more if required.
- Presenting the Task: The product owner or Scrum master introduces the user story or task, detailing its requirements.
- Team Discussion: Team members deliberate on the task's intricacies and requirements.
- Estimation Round: Members categorize the user story into one of the t-shirt size categories based on the perceived effort. Disagreements spark further discussion.
- Reaching Consensus: The team continues discussing until they mutually decide on a size category for the task.
Example: Designing a Logo
User Story: As a brand, we want a logo that represents our values and appeals to our audience.
Discussion might revolve around complexity, brand guidelines, and iterations.
Estimations:
- Designer A categorizes it as 'M', considering a few design iterations.
- Designer B thinks it's 'S', having a clear idea already.
After discussing design visions, the team settles on 'M' to accommodate potential iterations.
Benefits of T-Shirt Sizes Estimation:
- Intuitive and Relatable: Estimating with familiar sizes is often easier and less intimidating for teams.
- Avoids Anchoring to Specific Numbers: It’s a more flexible and fluid way of estimating.
- Easily Convertible: Teams can later convert these sizes to numbers (like story points) if required.
- Adaptable: Teams can introduce sizes like XXL or XXS based on project needs.
4. Affinity Estimating
Affinity Estimating involves grouping tasks or user stories that have a similar size or effort. It's a collaborative approach where discussions help in estimating tasks by comparing them with others.
Where Used: Mainly in Agile during the initial stages of product backlog creation.
Additional information: It's a visual and collaborative method, ideal for estimating a large number of items quickly.
How It Works:
- List All Items: All tasks or user stories are listed out.
- Group by Affinity: Items are grouped by perceived similarity in effort.
- Assign Estimates: Each group is then given an estimate based on its overall size or effort.
Example: Developing Website Modules
User Story: As a business, we want different modules like Contact, Gallery, and Testimonials on our website.
Discussion focuses on module functionalities and integration.
Estimations:
- The team groups Contact and Testimonials as similar in effort.
- They consider Gallery as slightly more complex.
The team assigns 2 days for Contact and Testimonials each, and 3 days for Gallery.
Benefits of affinity estimating:
- Collaborative: Involves the entire team, fostering team cohesion and understanding.
- Quick: Ideal for rapidly estimating a large number of items.
- Visual Representation: Helps in visualizing the relative effort of various tasks, aiding prioritization.
5. Bottom-up Estimating
Bottom-up Estimating involves breaking down larger tasks into smaller, detailed components and estimating them. Once all components are estimated, they are summed up to get the total effort. Very common and easy to understand concept
Where Used: Predominantly in Waterfall in budgets and schedule, due to its detailed nature but can also be found in Agile when breaking down user stories
Additional information: This technique is time-consuming but can yield accurate results due to its granularity. PMI define phases where it can be used. Technique require expert inputs, to determine scope. Very common during this estimation buffers are introduced that focused on reduce variability in estimations. Additional tools such as critical path are used to track work in progress.
How It Works:
- Decompose Tasks: Larger tasks are divided into smaller detailed tasks.
- Estimate Individual Tasks: Each smaller task is estimated separately.
- Aggregate Estimates: All individual estimates are summed to determine the total effort.
Example: Creating a Mobile App
User Story: As a user, I want a mobile app that helps me track my daily workouts.
Discussion revolves around UI/UX design, database setup, and features.
Estimations:
- UI Designer breaks down tasks: homepage (3 days), profile page (2 days), workout tracker page (4 days).
- Developer breaks down tasks: database setup (5 days), feature integrations (7 days).
- Additional time buffer 2 days added for possible uncertainty.
6. Top-Down Estimating
Top-down estimating, also referred to as "top-level estimating," involves starting with the highest level of the project and breaking it down into subordinate levels or sub-tasks. Senior management often uses this approach at the beginning of a project when there's little detail about the project. The estimate is often based on experience, historical data, or similar past projects.
Where Used: Early phases of the project, especially when detailed information isn't available. Suitable for both Waterfall, where the high-level scope is defined initially, and Agile, during initial product roadmap discussions.
Additional Information: While top-down estimating provides a rapid estimate, it's essential to revisit and refine the estimation as the project progresses and more detailed data becomes available. Often used as a starting point when other activities and resources are planned based on required top estimation.
How It Works:
- Initial Assessment: Senior managers or project stakeholders provide an initial estimate based on experience and broad project understanding.
- Decomposition: The high-level estimate is broken down into smaller tasks and sub-tasks as more information becomes available.
- Refinement: As tasks are defined in more detail, the estimate is refined.
Example: Building a new website.
User Story: A company wants a revamped website with a modern design, integrated e-commerce, and user-friendly UI/UX.
Discussion: Senior management might provide an initial estimate based on similar past projects, even if they don't know specific platform details or precise features.
Estimations:
- Manager A suggests it'll take 6 months, based on a similar previous project.
- Manager B believes it'll take 5 months because of advancements in website-building tools.
After an initial review of the company's requirements and resources, the team agrees on an estimate of 5.5 months, with the understanding that this will be refined as specifics are determined.
Benefits of top-down estimations:
- Quick Decision Making: Allows senior management to make quick decisions early in the project.
- Flexibility: Offers a higher degree of flexibility in the early stages, as detailed aspects of tasks are not yet defined.
- Strategic View: Provides a macro perspective on the project, ensuring alignment with strategic goals.
- Iterative Refinement: While initial estimates may be broad, they can be refined as the project progresses and more information becomes available.
7. Expert Judgment
Expert Judgment involves consulting with experienced and skilled experts to get their insights on the effort required. The approach taps into their knowledge, expertise, and experience.
Where Used: Most commonly in Waterfall, during Agile story point estimation, and Lean Six Sigma's define phase.
Additional information: This technique can be subjective but, when done with multiple experts, can offer valuable insights. It is especially useful when there is limited data or when the project is unique or required very specific skills that can't be easily acquired.
How It Works:
- Identify Experts: Teams bring in experienced professionals who are knowledgeable about the task at hand.
- Consultation Session: The experts assess the requirements, ask questions, and provide their estimates. They also point out possible risks and uncertainties
- Consolidate Feedback: The team gathers all expert opinions and determines the final estimation.
Example: Developing an AI Chatbot
User Story: As a company, we want an AI chatbot to assist our customers.
Discussion covers language processing, integration points, and user experience.
Estimations:
- AI Specialist A estimates 3 months considering the complexities.
- Developer B, with AI experience, suggests 2.5 months.
The team, considering the inputs, agrees on a 2.75-month timeframe.
Benefits of Expert estimations:
- Taps into Expertise: Harnesses deep knowledge and experience.
- Flexible: Useful in scenarios where there's limited data or where the project is unique.
- Comprehensive Insight: Multiple expert opinions can offer a well-rounded view of the task.
8. Analogous Estimating
Analogous Estimating is a technique that uses historical data from similar projects or tasks as a basis for estimating the current project. Essentially, it involves comparing the current task with a previously completed similar one and then adjusting the estimation based on the differences.
Where Used: Often seen in Waterfall, early stages of Agile projects, and in the planning phase of Lean Six Sigma.
Additional information: This method is quick but requires historical data. It's beneficial in the absence of detailed project information. Estimations might be less accurate if past data isn't truly comparable or large time frame passed or new events were introduced to the market (work shortage, high inflation, COVID-19 etc).
We compare on project-to-project costs, that is main difference with parametric estimations (see next)
How It Works:
- Review Historical Data: Teams review past projects or tasks to identify ones similar to the current task.
- Adjust for Differences: Adjustments are made based on any variations between past tasks and the current task.
- Finalize Estimation: After considering the differences and similarities, the team settles on an estimated effort or time.
Example: Setting Up an Online Store
User Story: As a business, we want to establish an online store for our products.
Discussion centers on the features required, design, and functionality.
Estimations:
- Project Manager A recalls a similar project took 4 weeks in the past.
- Developer B suggests it might take slightly longer due to additional payment gateway integrations.
After reviewing, the team agrees on a 5-week estimate.
Benefits of analogues estimations:
- Speed: This method is fast, especially when there's accessible historical data.
- Leverages Experience: Utilizes previous project experiences to make predictions.
- Consistency: By referring to past projects, teams can maintain a consistent estimation approach.
9. Parametric Estimating
Parametric Estimating uses statistical models and historical data to predict the effort. It involves using parameters from past data and applying them to the current task.
Where Used: Seen in Waterfall and during the planning of large Agile projects.
Additional information: It requires robust historical data and a good understanding of the relationship between variables. Very similar to analogues estimations, but requires parameters that will be used for estimation.
This method can be used to create quick estimations based on previous experience or industry standards, such as cost of 1sq ft of construction.
How It Works:
- Identify Parameters: Key parameters that impact effort are identified.
- Use Statistical Model: These parameters are plugged into a statistical model to get the estimate.
- Adjust for Current Task: Adjustments are made considering the specific requirements of the current task.
Example: Testing Software Modules
User Story: As a QA team, we want to test all modules of a software application.
Discussion addresses module complexities and previous test cycles.
Estimations:
- Historical data suggests it takes 2 hours to test a module of medium complexity.
- With 10 such modules, the base estimate is 20 hours.
- Add 5 hours time buffer for uncertainty
Considering some new features, the team adjusts the estimate to 25 hours.
Each of these techniques offers unique advantages, and their applicability depends on the project context, available data, and the team's preference.
Benefits of Parametric estimations:
- Data-Driven: Relies on statistical models, making it an objective method.
- Scalable: Can be used for small tasks or scaled up for larger projects.
- Continuous Improvement: As more projects are completed, the database grows richer, refining future estimations.
Conclusion:
Sergey
Estimation is a blend of art and science. While historical data, expert insights, and team consensus play crucial roles, the project environment, team dynamics, and external factors add layers of complexity. Continuous reviews, team growth, learning from past projects, and staying adaptable ensure that estimates evolve in accuracy and reliability.
