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

One manager I’ve worked with had the brilliant notion of “x2+1” time of what the dev says.

Anecdotally this has worked out remarkably well throughout my career - from single dev to cto - even stuff that I _new_ was going to take for example 2 days, if done properly ended up in like 5.

Didn’t matter if I was doing the estimate or someone else. At some point I just gave up and started doing the “my gut says 3 hours, so it must be 7 hours of work then, and send that up the chain. That cheeky “+1” had saved my ass more times than I can count.



One of the points of Scrum is that you don't estimate hours at all. You estimate intentionally vague and abstract "story points". You don't need to know what that is in hours, just try to make sure that two stories of roughly equal complexity have roughly equal points. Run a few sprints, check what velocity you actually end up on, and you've got the averages you need to give a slightly more long term planning.

But without the feedback of actually having done the work, any estimate is bound to be wrong.


I also generally have had good success with guessing a number and then multiplying it by 5 to get the time when it’s completely done, tested and documented.


I remember sitting in a meeting with the team discussing how we regularly failed to meet the our estimates and how this was bad.

I made exactly this suggestion and was laughed out of the room.

Granted this was for large and small estimates, but I still don't think it's the worst idea.




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

Search: