Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I disagree with the first part. The only thing less useful than estimating points is estimating hours.


I mean I agree, but it's because you should estimating in days.

No task significant enough to warrant a ticket in a queue and design effort takes less then a day. Even if you you swear it's "done", the more likely outcome is you'll be dealing with it for hours later that week when some sort of an issue crops up.

I've seen so many people "bid" 0.5 and 0.25 day units of time (in points or whatever) and then act offended when I challenge them on that, yet 3-4 days later they're still plugging away at the same task due to "complications".


Yep, I've been guilty of this in the past. Any estimate shorter than a day is for a task that wasn't worth the time to break it down and estimate it as a single unit. Like "modify firewall rules to allow traffic to port 1234" -- no, that's not a separate task, that's part of whatever task requires you to do that to get the whole thing to work.

And any task that is meaty enough to be a task will take at least a day, and probably longer.

The one place where I will more or less disagree is when bug-fixing. There are always some bugs where you pop open the debugger and have it solved in an hour or two. I've been at places where bug report tickets were handled differently from stories/tasks, though, so maybe this is fine to just think about separately.


If story points convert to "hours"/"days"/"time" in the end of the day, why is estimating in time less useful?

Asked in another way - why is it more useful to estimate in an unit that's more abstract/distant-from-reality?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: