Find out how wrong your estimates really are
Log predicted and actual task times. See your personal bias score update live. Get a correction factor you can actually use in tomorrow's planning meeting.
Log a task
Your estimation profile
Log at least 3 completed tasks to see your bias score.
Your estimate vs. actual trend will appear here after a few entries.
By category
No data yet.
Task history
| Task | Category | Predicted | Actual | Error | Note |
|---|
No tasks logged yet. Add your first one above, or load sample data to see how it works.
Why your estimates are off
Most people guess task duration based on the best-case version of the work. They imagine writing the code without bugs, the meeting without tangents, the review without rewrites. The real world does not cooperate.
This tracker does not judge you. It just shows the gap between what you predicted and what happened. After 10 or 15 entries, the pattern is hard to ignore. That is the point.
How to use the correction factor
Say your bias factor is 1.6. That means tasks take about 1.6 times longer than you think. Next time you estimate a task at 2 hours, multiply: 2 × 1.6 = 3.2 hours. Block 3 hours and 15 minutes instead.
This is not about padding estimates to look safe. It is about being honest with yourself and your team so commitments actually hold.
Common mistakes when estimating
- Ignoring context switches. A 30-minute task takes 45 minutes when you check Slack every 10 minutes. Log the real wall-clock time, not the focused time.
- Forgetting setup and cleanup. Pulling the branch, reading the ticket, writing up the PR. These minutes add up.
- Grouping unlike tasks. A quick bug fix and a deep refactor are both "coding" but behave very differently. Use specific categories.
- Only logging the bad misses. Overestimates matter too. If you padded everything by 2x, your factor would be below 1.0. Log everything.
What the numbers mean
Bias factor near 1.0: You are well calibrated. Estimates match reality on average.
Factor above 1.0: You underestimate. A factor of 1.5 means things take 50% longer than you think.
Factor below 1.0: You overestimate. This can be as problematic because it leads to sandbagging and lost capacity.
Average error: The mean absolute difference between predicted and actual, in minutes. Lower is better.
Using this with a team
Each person keeps their own log in their browser. During a retrospective, everyone shares their bias factor. The team can agree on a shared correction factor for sprint planning.
Use the share link button to generate a URL with your data encoded. Paste it in a team doc or chat. No accounts, no servers, no tracking.
Data and privacy
All data lives in your browser's local storage. Nothing is sent to any server. If you clear your browser data, your history goes with it. Export a JSON backup if you want to keep a copy.
The share link encodes your data in the URL itself using base64. It is not stored anywhere. The link can get long if you have many tasks.