Estimation & Planning
Defending the timeline. Master High-Level vs Detailed estimation techniques to secure the time your team needs.
1 The Hook
A Project Manager walked up to a new Test Manager and asked: "We are building a new mobile app. It will take the Devs 3 months. How long will testing take?"
The Test Manager guessed: "Uh, probably 3 weeks?" Two months later, the project ran late, and testing was blamed for the delay because they hadn't accounted for environment setup, data masking, or UAT support. An estimate is not a guess; it is a mathematical defense of your team's time.
2 The Rule
Never give a detailed estimate without detailed requirements. Use "High-Level Estimation" when uncertainty is high, and transition to "Detailed Estimation" only when the scope is locked.
3 Watch Me Do It: The Two-Phase Model
Observe how a Test Manager handles estimation at different stages of the project lifecycle.
| Phase | Technique Used | The Output |
|---|---|---|
| Project Feasibility (Month 1) Requirements are vague. |
High-Level Estimation (Top-Down) Using industry ratios (e.g., Testing is 30% of Dev effort) or Wideband Delphi (Expert consensus). |
"Testing will require between 4 to 6 weeks and 2 QA resources." |
| Test Planning (Month 3) Requirements are locked. |
Detailed Estimation (Bottom-Up / WBS) Breaking down exact tasks: Test Design (40hrs), Execution (80hrs), Data Setup (16hrs). |
"Testing requires exactly 136 hours, plus a 20% contingency, totaling 163 hours." |
4 Estimation Lab: The WBS Breakdown
In this lab, you must defend your testing timeline against a Project Manager who wants to "cut testing in half."
Your Task: Defending the 100 Hours
You estimated 100 hours for testing a new API. The PM says: "It's just an API, why does it take 100 hours to run Postman? You have 50 hours."
BUILD YOUR DEFENSE (WBS):
- Preparation: How long does it take to write the automation framework and secure the test data? (e.g. 30 hours).
- Execution: Running the tests, including negative and security scenarios (e.g. 40 hours).
- Triage & Rework: Logging bugs, attending triage boards, and re-testing fixed code (e.g. 20 hours).
- Contingency: The standard 10% buffer for environment downtime (e.g. 10 hours).
The PM still wants to cut it to 50 hours. What do you say? Write your response in your notes. (Hint: "If we cut hours, we cut scope. Which module do you want to release untested?")
5 Planning Poker: Team-Based Estimation
When estimating as a team, Planning Poker prevents anchoring bias (where the first number said influences everyone else). Each person estimates independently, then discusses.
How It Works (15 minutes)
- Read the Story: The Product Owner reads a story (e.g. "Test the new payment gateway for Visa, Mastercard, and Apple Pay").
- Ask Questions: Testers ask clarifying questions. "Do we test international cards?" "What about 3D Secure?"
- Estimate Silently: Each person selects a Fibonacci number (1, 2, 3, 5, 8, 13, 21) representing story points. Use this scale: 1pt = 2 hours, 5pt = 1 week, 13pt = beyond one sprint (split the story).
- Reveal Together: Everyone shows their estimate simultaneously. If estimates match (all 8s), great! If not, discuss the outliers.
- Re-estimate: The high estimator explains why (e.g. "We need new test data for international scenarios"). The low estimator defends their estimate. Re-vote once.
Fibonacci Scale for Testing Stories
| Points | Hours | Example Testing Task |
|---|---|---|
| 1 | 2-4 | Test a single happy-path API endpoint. No data setup needed. |
| 2 | 4-8 | Test a simple form with 5 fields. Include basic negative tests. |
| 3 | 8-12 | Test a checkout flow (multiple screens, data validation, edge cases). |
| 5 | 12-24 | Test a new payment gateway (multiple card types, error scenarios, integration with inventory). |
| 8 | 24-40 | Test a complex feature (performance testing, security testing, cross-browser). |
| 13+ | 40+ | STOP. This is too big. Break it into smaller stories. |
6 Velocity Forecasting & Capacity Planning
Once your team has completed 3-4 sprints, you can measure "Velocity" (story points completed per sprint). Use this to forecast future capacity and plan for NZ holiday disruptions.
Velocity Worksheet: Summer Holiday Impact (Dec-Jan)
Scenario: Your team has an average velocity of 40 story points/sprint. In December and January, many NZ staff take leave. Calculate available capacity.
| Sprint | Team Size | Leave Days | Available % | Velocity |
|---|---|---|---|---|
| Nov (Normal) | 5 testers | 0 | 100% | 40 pts |
| Dec (Holidays Start) | 5 testers | 8 (Summer starts) | 60% | 24 pts (40 x 0.6) |
| Jan (Peak Holidays) | 5 testers | 15 (Xmas + New Year) | 30% | 12 pts (40 x 0.3) |
| Feb (Return) | 5 testers | 2 | 92% | 37 pts (40 x 0.92) |
Lesson: Don't plan 120 story points for Dec-Jan if your team is NZ-based. Plan 36 points. The gap (84 points) must either be: deferred to Feb-Mar, or backfilled with contractors.
Capacity Calculator Template
Fill this in at the start of each quarter to forecast team capacity.
| Factor | Value | Notes |
|---|---|---|
| Team Size (FTE) | __ | e.g. 5 testers |
| Hours per Tester per Sprint | __ | e.g. 40 hours (1 week) |
| Testing % of Time | ___% | e.g. 70% testing, 30% meetings/admin |
| Available Testing Hours | __ | e.g. 5 x 40 x 0.7 = 140 hours |
| Scheduled Leave (days) | __ | Holidays, training, sick leave buffer |
| Leave Impact (%) | ___% | If 10 days leave total: 10 / 50 = 20% |
| Adjusted Hours | __ | e.g. 140 x 0.8 = 112 hours available |
| Story Points Available | __ | If 1pt = 4 hours: 112 / 4 = 28 points |
7 Buffer Estimation: Risk, Complexity, & Unknowns
A good Test Manager doesn't just estimate; they add buffers for the unexpected. In testing, the unexpected ALWAYS happens.
Risk-Based Buffer Template
For each major testing phase, assign a risk score and calculate the buffer.
| Phase | Base Estimate | Risk Factors | Risk Score | Buffer % | Final Estimate |
|---|---|---|---|---|---|
| Test Design | 40 hrs | Requirements still changing | Medium (2/5) | +10% | 44 hrs |
| Test Data Setup | 20 hrs | DB access often delayed; master data incomplete | High (4/5) | +30% | 26 hrs |
| Execution | 80 hrs | Environment stability unknown; new team learning curve | High (4/5) | +25% | 100 hrs |
| Triage & Rework | 30 hrs | Devs are slow to fix bugs; re-test queue backs up | Medium (3/5) | +15% | 35 hrs |
| TOTAL | 170 hrs | +20% overall | 204 hrs |
Rule of Thumb: If your estimate is under 80 hours, add 15%. If it's 80-160 hours, add 20%. If it's over 160, either split the story or add 25%.
8 Common Mistakes
⚠ Estimating only "Execution Time"
Why it fails: Test Execution is only 40% of the job. If you forget to estimate Test Data Creation, Environment Provisioning, and Defect Triage, your project will run late.
⚠ Yielding to "Deadline Pressure"
Why it fails: If the Devs are late by 2 weeks, the project deadline rarely moves. The PM will ask you to "compress" testing. Never compress the estimate without explicitly dropping test scope and documenting the accepted risk.
⚠ Forgetting Holiday Impact
Why it fails (NZ-specific): December and January are tsunami months for leave in NZ. If you don't plan for 30-40% capacity reduction, your project drowns in Jan-Feb.
9 Self-Check
Q1. What is Wideband Delphi?
A consensus-based estimation technique where a group of experts anonymously estimate a task, discuss the outliers, and re-estimate until they reach an agreement. Great for High-Level estimation.
Q2. Why do we include a "Contingency" buffer?
Testing is volatile. Environments crash, data gets corrupted, and builds fail. A 15-20% contingency protects the timeline from inevitable technical friction.
Q3. In Planning Poker, why use Fibonacci numbers instead of 1-10?
Fibonacci forces conversations about big differences. The gap between 5 and 13 is huge; you'll definitely discuss it. The gap between 5 and 6 feels insignificant, so you might miss real risk.
Q4. How should you adjust testing estimates for NZ summer holidays?
Reduce velocity by 30-40% in Dec-Jan. If normal velocity is 40pts/sprint, expect 12-28 pts during holiday season. Plan accordingly or bring in contractors.