Estimation Approaches

3.Estimation Approach In SCRUM

A.Life Before Agile:

There were different sizing models, to estimate the size, and the effort accordingly: 

• FPA (Function point analysis): Build estimation around required functionality, before object oriented analysis phase

• UCP (Use case point): Build estimation around resulted use cases

• COCOMO & COCOMO II: Cocomo (Constructive Cost Model) is a regression model based on LOC

• Delphi: Consensus model

B.Life In Agile:

 You can use the previously mentioned models, but Agile has moved for a new sizing approach called the Poker technique, taken from the Poker cards, which can be described as follows:

• Consensus model, as all team members discuss the estimation and approve the approach

• Around the reference point: Definition for sizing reference point will be taken to decrease the sizing variance across team members, for example, agreement on the size of login screen, or feedback screen.

• Using the Fibonacci series

  • a series of numbers

  • Each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, etc.

  • Why use this approach?

    • enable the slicing of the stories

C.How to make the reference point clear?

• Select a Baseline Story: Choose a user story everyone understands well., Example: “Login page with username/password validation” = 3 points.
  
  

• Document Why It’s the Baseline: Note effort, complexity, and risk, and best approach is to use MDA approach for modeling:

  • Use cases for the functionality

  • Sequence diagram that will mention objects and expected operations.
    
    

• Periodically Recalibrate: If team velocity or size changes, revisit the reference.

D.Sizing Meeting:

• All the team should share the estimation process

• Reference Point for sizing take place

• Poker Estimation Technique

• Poker Card numbers

  • Zero

  • Unknown

  • Setting limits

• Discussion mechanism

  • PO clarify the user story

  • Discussion takes place between the Upper estimation and the lower estimation

• Map Points detailed estimation: For example, 1 point = 2 Days

E.Estimation using Scrum Poker Application

• Download scrum poker application

• Use Fibonacci model

• Each member pick the estimation according to the reference point, hiding the selected number

• The anomalies (Upper and lower estimations) should have a public discussion in order to brainstorm the variance

• Re-Estimate again, till having consensus between the team

G.Best Practice:

 Combine techniques depending on project stage:

• Early Phase → T-shirt sizing, affinity

• Refinement → Story points, poker

• Release Planning → Velocity-based forecasting

Agile = flexible, not one-size-fits-all.

4.Estimation Governance Model

As most of enterprises suffer from the sizing process, in this section we are going to govern the estimation process as following:

A.Scope Definition

• Feature-based vs Story-based
  Feature-based scope defines what business capability will be delivered, while story-based scope focuses on how it is incrementally implemented. Best practice is to estimate at feature level for predictability, then refine using stories for sprint execution.

• Scope Governance – 4C
  Scope governance ensures estimates are credible and controlled by validating scope against four quality dimensions before sizing.

• Completeness
  All required functional and non-functional elements are identified. Missing scope is the primary root cause of under-estimation.
  
  

• Consistency
  Scope is aligned across business, architecture, and delivery teams. Inconsistencies create rework and invalidate estimates.
  
  

• Correctness
  Scope accurately reflects business intent and constraints. Incorrect scope leads to false confidence in delivery dates.
  
  

• Clarity
  Scope is unambiguous and measurable. Clear scope reduces interpretation risk and estimation variance.
  
  

B. Sizing Approach

• Design-based Sizing
  Sizing is anchored to solution design, architecture complexity, and integration points rather than vague requirements. This aligns effort with real technical work.

• Reuse Engineering Consideration
  Ready components reduce effort only when integration, customization, testing, and ownership are explicitly sized. Reuse ≠ zero effort.

• Non-Functional Consideration
  Performance, security, availability, compliance, and scalability must be sized explicitly, as NFRs often consume 30–50% of total effort.

C. Estimation Pitfalls

• Big Sizing Unit (Sprint-Based)
  Estimating only in sprints hides true scope size and creates false predictability. Sprint counts are execution metrics, not estimation units.

• Absence of Dependencies
  Ignoring technical, vendor, or organizational dependencies results in optimistic timelines and unmanaged delivery risk.

• Absence of Assumptions
  Unstated assumptions invalidate estimates. Every estimate must have explicit assumptions documented and approved.

• Ignoring Team Quality
  Velocity varies by team capability, stability, and experience. Assuming all teams perform equally leads to systemic estimation errors.

• Lack of Ownership
  Estimates without a clear accountable owner degrade quickly. Ownership ensures estimates are defended, updated, and governed.

• Eliminate Over-Engineering
  Over-design inflates effort without proportional business value. Estimation must reflect fit-for-purpose, not theoretical perfection.

D. Estimation Governance

• Reference Point Sizing
  Using historical, proven reference solutions creates calibration and reduces subjectivity across teams and initiatives.

• Yearly Estimation Defense (Management)
  Annual reviews validate strategic assumptions, capacity models, and investment realism at portfolio level.

• Quarterly Estimation Defense (Management)
  Quarterly checkpoints reassess scope changes, risk exposure, and forecast accuracy to prevent drift.

• Sprint-Based Estimation Defense (Team)
  Sprint-level defense validates execution realism, surfaces blockers early, and continuously improves estimation accuracy.

7.Finding estimation issues: Over/Under

• Compare planned vs. actual effort: Compare the effort estimated at sprint planning with the actual effort required to complete the work.

• Monitor progress during the sprint: Compare the percentage of completed work with the percentage of sprint time elapsed. Significant gaps should trigger investigation.

• Compare with historical velocity: Compare the current commitment with the team's average velocity over the previous 3–5 sprints.

• Calculate estimate accuracy:
  Estimate Accuracy = Actual Effort ÷ Estimated Effort
  A ratio consistently below 1.0 may indicate over-estimation.

• Analyze remaining work: If a large amount of work remains late in the sprint while significant capacity has already been consumed, review whether the original estimates were excessive or whether other factors affected delivery.

• Check completed stories: Identify stories that were consistently estimated at high points but completed with significantly less effort than expected.

• Look for recurring patterns: One inaccurate estimate is normal. Repeated over-estimation across several sprints indicates a potential estimation problem.

• Separate estimation from delivery problems: Low delivery does not automatically mean over-estimation. Check for dependencies, production support, defects, scope changes, technical debt, interruptions, and excessive WIP.

• Use tolerance thresholds:
  🟢 ≤10% variance — Healthy
  🟡 10–20% variance — Investigate
  🔴 >20% consistently — Potential estimation/capacity issue

8.Moving To Schedule from Estimation

1. Validate Scope: Confirm requirements, deliverables, assumptions and acceptance criteria.

2. Decompose Activities: Break features into manageable tasks (WBS).

3. Validate Effort Estimates: Include development, testing, integration, deployment and documentation.

4. Identify Dependencies: Define task sequences and predecessor/successor relationships.

5. Calculate Resource Capacity: Consider actual availability, meetings, leave and operational commitments.

6. Determine Task Duration: Convert estimated effort into realistic calendar time.

7. Identify Critical Path: Prioritize activities that directly affect the final delivery date.

8. Optimize Parallelism: Execute independent activities simultaneously where feasible.

9. Balance Workload: Allocate tasks according to skills, capacity and resource availability.

10. Include Quality Activities: Schedule code reviews, QA, security testing, UAT and defect resolution.

11. Optimize Resources: Avoid bottlenecks, unnecessary resource overlap and overstaffing.

12. Automate Processes: Leverage CI/CD, automated testing and deployment to reduce effort and cost.

13. Prioritize Scope: Deliver high-value features first and defer nonessential requirements.

14. Include Contingency: Reserve risk-based buffers for uncertainties and external dependencies.

15. Establish Milestones: Define measurable delivery checkpoints and approval gates.

16. Baseline the Schedule: Obtain agreement on scope, timeline, resources, budget and quality.

17. Monitor Performance: Track actual versus planned progress, effort, cost and defects.

18. Reforecast Continuously: Update the schedule based on actual performance and emerging risks.

Related Topics

1. Scrumban

2. XP

3. Estimation Approaches