Part 014 — Estimation Techniques, Capacity Planning, and Forecast Confidence

Positioning

Forecasting adalah penggunaan evidence untuk memperkirakan apa yang mungkin selesai.

Forecast bukan commitment absolut.

Core thesis: forecast yang sehat menggabungkan historical data, current capacity, work uncertainty, dan explicit assumptions.

1. Planning Poker

Planning poker flow:

1. Present story.
2. Clarify.
3. Estimate independently.
4. Reveal simultaneously.
5. Discuss divergence.
6. Re-estimate.
7. Stop when sufficient agreement exists.

Why simultaneous reveal matters

Prevents anchoring.

Who speaks first

Ask:

• lowest estimate;
• highest estimate.

They usually hold different assumptions.

2. When Planning Poker Is Useful

Useful when:

• team is stable;
• work is comparable;
• discussion value high;
• and scale understood.

Less useful when:

• work is operational and flow-based;
• urgent;
• highly uncertain;
• or already decomposed into standard tasks.

3. Affinity Estimation

Useful for many items.

Process:

• place items relative to each other;
• group similar size;
• assign scale later.

Good for roadmap or backlog cleanup.

4. Three-Point Estimation

Estimate:

• optimistic;
• most likely;
• pessimistic.

Useful for high uncertainty.

Do not present weighted result as certainty.

5. Capacity Planning

Capacity is not headcount × working days.

Real capacity includes:

• leave;
• public holiday;
• support;
• on-call;
• meetings;
• training;
• review;
• incident;
• dependency wait;
• and onboarding.

Capacity model

Nominal capacity
- known absence
- fixed obligations
- support allocation
- expected interruption
= planning capacity

6. Focus Factor

Focus factor approximates how much nominal time becomes delivery time.

Use cautiously.

It should not become utilization target.

100% utilization creates queues and destroys responsiveness.

7. Velocity

Velocity is amount of estimated work completed in a Sprint.

It is:

• team-local;
• historical;
• dependent on estimation scale;
• and influenced by Definition of Done.

It is not:

• productivity;
• quality;
• business value;
• or cross-team comparison.

8. Velocity as Forecast Input

Use rolling history.

Example:

Last 6 Sprints:
28, 31, 25, 29, 27, 30

Likely range:
25–31

Do not promise average as exact capacity.

9. Throughput

Throughput = number of items completed per period.

Useful when items are similarly sliced.

If item size varies widely, throughput can mislead.

10. Cycle Time

Cycle time = start to completion.

Forecasting can use historical cycle-time distribution.

Example:

• 50% within 4 days;
• 85% within 7 days;
• 95% within 10 days.

This gives probability, not certainty.

11. Monte Carlo Concept

Monte Carlo forecasting simulates many possible futures using historical throughput or cycle time.

Outputs may answer:

• how many items by date;
• when a number of items may finish;
• with probability ranges.

Use only if data quality is reasonable.

12. Forecast Confidence

Every forecast should state confidence.

Example:

Forecast:
6–8 items by Sprint end

Confidence:
70%

Assumptions:
- no production incident
- dependency available by day 3
- story size remains similar

13. Commitment versus Forecast

Commitment in Scrum applies to goals and quality.

Forecast applies to scope and timing.

Team can commit to:

• Sprint Goal;
• Definition of Done;
• transparency;
• and adaptation.

Team forecasts:

• backlog items;
• delivery date;
• release range.

14. Capacity Buffers

Buffer can protect against:

• unplanned support;
• defects;
• dependency delay;
• and discovery.

Buffer should be based on historical evidence.

Avoid arbitrary 20% rules without context.

15. Carry-Over

Carry-over is a signal.

Investigate:

• oversized stories;
• late QA;
• dependency;
• WIP;
• scope change;
• hidden work;
• or estimation mismatch.

Do not automatically carry story without re-evaluation.

16. Forecasting Release Scope

Release forecast should include:

• ordered backlog;
• throughput/velocity range;
• uncertainty;
• dependency;
• scope flexibility;
• and target confidence.

Example

Must-have:
A, B, C

Should-have:
D, E

Could-have:
F, G

Confidence:
- Must-have by date: 80%
- Full scope by date: 45%

17. Integration-Heavy Forecasting

Integration work adds:

• external queue;
• contract risk;
• environment risk;
• and sequencing.

Model dependency explicitly.

Do not hide it inside estimate only.

18. Production-Sensitive Forecasting

Include:

• release window;
• validation;
• rollout;
• observation;
• rollback;
• and support readiness.

Coding complete is not release complete.

19. Forecast Update

Forecast should change when evidence changes.

Triggers:

• scope change;
• dependency delay;
• incident;
• new risk;
• failed validation;
• or capacity loss.

Updating forecast is good governance, not failure.

20. Planning Poker Anti-Patterns

• authority reveals first;
• discussion focuses on defending numbers;
• team averages votes;
• manager changes estimate;
• estimate used as deadline;
• re-estimation used to hide poor performance;
• and point scale becomes too granular.

21. Velocity Anti-Patterns

Velocity target

Gaming.

Cross-team comparison

Invalid scales.

Individual points

Destroys collaboration.

Partial credit

Inflates progress.

Point inflation

No real capacity increase.

Ignoring quality

Higher velocity with more defects.

22. Forecasting Failure Modes

Single-date certainty

No range.

No assumptions

Stakeholders cannot interpret risk.

Average-only planning

Variation ignored.

Historical data mismatch

Team or work type changed.

Hidden queues

Review and QA wait excluded.

Fixed scope and date

Quality becomes hidden variable.

23. Senior Engineer Operating Model

During estimation

• avoid anchoring;
• reveal hidden work;
• explain dependency;
• propose slicing.

During capacity planning

• include review, support, and operational work;
• protect sustainable pace;
• avoid 100% allocation.

During forecasting

• use ranges;
• state assumptions;
• expose confidence;
• update early.

With stakeholders

Provide options:

Option A:
Smaller scope, higher confidence.

Option B:
Full scope, lower confidence.

Option C:
Later date, higher confidence.

24. Worked Example: Multi-Tenant Approval Rollout

Scope

• approval rule;
• tenant configuration;
• audit;
• migration;
• rollout.

Historical evidence

• team completes 5–7 similarly sliced stories per Sprint.

Forecast

Sprint 1:

• compatibility;
• configuration;
• pilot tenant.

Sprint 2:

• migration;
• more tenants;
• operational tooling.

Confidence reduced by customer configuration dependency.

25. Delivery Metrics Context

Use metrics together:

No single metric represents health.

26. Internal Verification Checklist

Estimation

• Is planning poker used?
• Who participates?
• Are estimates revealed simultaneously?
• What scale?
• Are reference stories documented?

Capacity

• How are leave and support handled?
• Is on-call visible?
• Is review work included?
• Is buffer used?
• How is onboarding counted?

Velocity

• How many Sprints are used?
• Is velocity a target?
• Is it compared across teams?
• Is partial credit given?
• Has Definition of Done changed?

Forecast

• Are ranges used?
• Are assumptions stated?
• Are confidence levels shared?
• How often is forecast updated?
• Are dependencies modeled explicitly?

Data

• Are throughput and cycle time available?
• Is aging visible?
• Is historical data trustworthy?
• Are work types mixed?

27. Practical Exercises

Exercise 1 — Capacity model

Calculate:

Nominal days:
Leave:
Support:
Meetings:
On-call:
Planning capacity:

Exercise 2 — Velocity range

Use last six Sprints and create a range, not one average.

Exercise 3 — Forecast assumptions

Take one release forecast and list hidden assumptions.

Exercise 4 — Option framing

Create scope/date/confidence options for a stakeholder.

Exercise 5 — Metric triangulation

Compare velocity, throughput, cycle time, and defect trend.

28. Part Completion Checklist

You are done if you can:

• facilitate planning poker;
• use affinity and three-point estimation appropriately;
• calculate realistic capacity;
• interpret velocity correctly;
• use throughput and cycle time;
• explain forecast confidence;
• distinguish commitment and forecast;
• and communicate ranges and assumptions.

29. Key Takeaways

1. Planning poker is for shared understanding.
2. Capacity is less than nominal availability.
3. Velocity is team-local historical data.
4. Velocity is not productivity.
5. Forecasts need ranges.
6. Confidence and assumptions must be explicit.
7. Carry-over is a system signal.
8. Integration and rollout belong in forecast.
9. Forecasts should adapt to evidence.
10. Internal metric practices must be verified.

30. References

Conceptual baseline:

• The Scrum Guide.
• Agile estimation and forecasting practices.
• Flow metrics and probabilistic forecasting concepts.

These concepts do not describe internal CSG processes.