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.
Senior engineer insight
The moment that changed how I think about estimation was watching a Test Manager present a 200-hour estimate to a Steering Committee, get it halved on the spot, and then silently accept it. The estimate was sound — it included data masking, UAT coordination, and regression regression. What was missing was the defence: a WBS printout, a risk register, and a one-page scope-cut table. Committees don't argue with a spreadsheet that shows exactly what you're dropping. From that point on, I never walked into an estimation review without a written scope-reduction menu — if you want 100 hours instead of 200, here is the list of modules that will ship untested, and here is your signature line.
The most common mistake at Test Manager level is delivering a single number without a breakdown — a bare total is an invitation to negotiate, a WBS is a contract.
From the field
On a NZ central-government digital transformation programme, the test team submitted a 340-hour estimate in the business case that went to Treasury for funding approval. The assumption was that the integration layer was a simple REST wrapper over a legacy mainframe. When detailed design arrived three months later, the team discovered the mainframe exposed a batch-file interface — no API, no real-time handshake, just flat files dropped on an SFTP server every four hours. The contingency that had been set at 15% (standard Treasury guidance at the time) evaporated in the first sprint of execution. The Test Manager had to return to the Programme Board with a revised 510-hour figure, triggering a change-request process that cost four weeks of schedule. The lesson that generalises: whenever your estimate feeds a formal business case or Treasury approval, build a separate integration-uncertainty buffer on top of your normal contingency, and document the assumptions that would invalidate it — because someone will re-read that business case eighteen months later.
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.
Why teams fail here
- Estimating only execution hours and ignoring the surrounding work — test design, data setup, environment provisioning, triage attendance, and UAT facilitation typically add 60-80% on top of raw execution time.
- Giving a single-point estimate instead of a range — a confident “136 hours” invites the PM to treat it as a ceiling and negotiate down; a range (“130–160 hours depending on defect rate”) anchors the conversation at the realistic midpoint.
- Failing to document the assumptions behind the estimate — when the scope changes, the team has no written baseline to point to, so the original estimate gets blamed rather than the requirements drift.
- Absorbing schedule compression silently — accepting a PM’s “can you do it in half the time?” without formally recording which test coverage has been removed creates a liability that lands on the test team when defects escape to production.
Key takeaway
An estimate is not a guess you defend once — it is a living contract that documents what you will test, what you will not test, and exactly what needs to change if the PM wants either of those columns to move.
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.