Almost everyone underestimates, and almost everyone believes they are the exception. The only way to find out is to write the estimate down before the work and the actual after it, enough times that the pattern stops being deniable.
The one rule that makes this work: never edit the estimate after the fact. The moment you adjust an estimate to match what happened, the log stops measuring anything and starts flattering you.
A ratio of 2.0 means the task took twice as long as you thought. A ratio of 1.0 means you called it exactly.
| Here | Jira | What teams actually argue about |
|---|---|---|
| Estimate (hours) | Original Estimate | Whether to estimate in hours at all |
| Actual (hours) | Time Spent / worklog | Whether logging time is useful or surveillance |
| Your ratio | no direct equivalent | Most teams never compute this, which is why they keep missing |
| — | Story Points | Relative size, deliberately not hours |
| — | Velocity | Points completed per sprint — a team's empirical ratio in disguise |
Story points exist largely because hour estimates are so unreliable. A team estimates relative size, measures how many points it actually finishes per sprint, and plans from that measured number instead of from anyone's optimism. Velocity is the team-scale version of what this tool computes for one person. It is also routinely misused as a productivity metric by managers, which is why engineers get twitchy about it.
| Date | Task | Type | Est. | Actual | Ratio | Actions |
|---|
| Type | Finished | Median ratio | Reading |
|---|
Log a few finished tasks and observations will appear here.
Log some finished tasks first.
This multiplies your estimate by your own measured median. It is not a prediction — it is your track record applied to your optimism.