1. Start with the decision
Before opening a forecast, name the decision it should support. A release commitment, a scope tradeoff and a capacity discussion need different context. Record the target date, the current scope and the person responsible for the next decision. A probability is useful when the team can explain what it is deciding and what would change its mind.
2. Check the inputs together
Review completed work, outstanding tasks and dependencies before interpreting the chart. Look for stale statuses, work that has not been recorded and tasks blocked on a decision outside the project. Throughput history is less informative when the team, process or type of work has changed. Capture those differences alongside the forecast rather than treating the output as a complete account of the project.
3. Read a range, then inspect a scenario
The public forecast example uses fictional records and a seeded simulation. Its scope slider lets you explore how an additional amount of work changes the simulated delivery distribution. Compare the original scope with a realistic alternative, then look at the cumulative probability and percentile dates together. These examples explain an interface; they do not measure production forecasting accuracy or predict your team’s delivery.
4. Turn the review into an action
A useful review ends with an owner and a question to resolve. That might mean confirming a dependency, reducing scope or checking available capacity. Record the assumption behind the action so the next review can tell whether it still holds. Revisit the estimate when the work changes and keep a proposed date separate from a commitment your team has approved.