How often your task estimates end up being accurate?
From time to time
Once in a while
94 votes · Closed
Hi, ladies and gents.
Here's my confession: I'm terrible with estimates. Partially because of my coding standards - people call me perfectionist (and I wholeheartedly disagree), but what about you? What's your story?
At work, I'd say most of the time, however we use Scrum, so we don't estimate time; we estimate complexity. We have a rough story with a given number of points and we compare the task to be estimated against it. We get a consensus using planning poker, and that's usually pretty spot on.
At home, for my private customers, I do have to estimate time, and I'd say I am right quiet often. I split up my tasks into small tasks for which it is easy to estimate how long it will take to implement them. Then I add them up and double the total. That's what I tell my customer. I usually finish way ahead (remember: I doubled the time), however the extra time lets me work on things in parallel or be spontaneous about how I spend my time.
Iʼm getting better, but it will never be perfect. What i noticed, though, is that iʼm usually spot on when estimating othersʼ time.
Us humans tend to show ourselves as better than we actually are. Thatʼs a fact and doesnʼt really change between different cultures, either. So at our company we are currently trying to estimate how much a task will take for someone else (who will actually work on that task).
Another thing you should take into consideration is that time estimates are usually net times: “if i can work on this uninterrupted, it will take this much”. However, this is almost never the case. We tend to get interrupted, and context switching is not cheap for most people. Thus, you should multiply the estimates at least by two.
After a long career, both developing and running teams, I am happy if the actual time is between 50% and 150% of the estimate. I try and adopt methodologies that focus on delivering value continuously rather than trying to deliver all the value at a specific point in time. If the product is always in a deliverable state, but maybe short on features, then it can actually be delivered at any time - in fact, it can be delivered continuously 😉
I think this is related to the experience, I mean the more one contributes to projects the more his time management is improved.
I voted for "From time to time", since estimates based on planning sessions are dependent on the team member and their role. However, I would recommend thinking "shirt sizes" rather than "hourly". Also, review the past few sprints. I find this extremely effective for me in recognizing patterns within different workflows, which basically dictates what's worked in the past for similar issues (relative to the person that they've been assigned to.)
On a personal level, I would actually vote "Quite often". Because there's no guessing game involved, and I'm fully aware of other issues that life might throw me, which a Scrum Master would not be aware of.
I'm generally pretty close to my estimates if I can see the code in my head before I even begin. If it's something out of my comfort zone that I've never done before, I allow room for research and learning. But, if I pretty much know what needs to be done, my estimate includes what I think it will take me, including testing, multiplied by 3. This is my version of the Scotty Factor .
I tend to be pretty spot-on. I'm pretty good at giving conservative estimates at this point... Meaning, I factor in time for the unexpected, which almost always inevitably happens. I prefer to overestimate and outperform than to underestimate and underperform.