A task was estimated at three days and took five. Should you change “3” to “5” in the planning table? You need to record the five days, but keeping the original estimate also lets you look back at why the task took longer.
The key idea
Keep separate fields for the original plan, the actual result, and the current forecast. You can then share the latest expected finish while still seeing how it differs from the plan.
Use separate fields for the three numbers
Keep effort in person-days separate from the elapsed days between starting and finishing. Compare values that use the same units. If you formally revise the plan, keep the previous version and the reason for the change.
| Field | What to record |
|---|---|
| Plan | The originally agreed estimate |
| Actual | The effort or duration actually required |
| Forecast | The currently expected outcome |
| Variance | The difference between plan and actual, or plan and forecast |
| Reason | The cause of the difference and the facts that support it |
Update the forecast when the expected finish changes
If a task is likely to take longer, share that early and update the forecast. The original estimate alone will not tell the team when the work is now expected to finish.
Keep the original plan alongside the new forecast so you can explain what changed. You can still replan when needed; just retain enough history to understand the change.
Record why the work took more or less time
QA can take longer for several reasons: time spent clarifying specifications, waiting for an environment, adding test perspectives, or retesting defects. Record these separately so you can see where the time went.
A longer duration alone does not tell you about the quality of the work or the ability of the person doing it. The reasons for the difference are more useful when preparing or estimating the next task.
Keep the plan useful as the work changes
The Scrum Guide describes the Sprint Backlog as a plan that changes as the team learns. The fields in this article are one suggestion for recording forecasts and history. Scrum does not require this format.
A table is more useful when it shows what happened and why. Keep those details so the team can discuss what to adjust next time.
References
QA Notebook / Teams & process
Read nextHow to write a work message that is easier to answerBack to all articles