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?
Learn Something New Everyday,
Connect With The Best Developers!
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.
Mihai Deta Planning Poker is the name of an agile/scrum technique. Roughly, you present a ticket to the team, and everyone gives their own numerical estimation of the complexity at the same time without talking about it. You can read more about it on Wikipedia.
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.
Yep, can't argue with that. Though that's mostly for tasks that are somewhat related to what you already created / modified yourself. Those can be estimated with a larger confidence. Unlike the other type of tasks when you're supposed to do something you've never done before.
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 .