4 ms·

If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you

If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all? I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preference is to ask devs for just the tightest bounds to timeframe they're actually comfortable with, then estimate based on that and pass up the chain. I consider it to be on my shoulders if things take longer than I communicated upwards.

maxxxxx 7y ago
I understand that estimates are important and I give estimates. But recently in my company it’s fashionable to talk about “commitments” and I won’t give those. In my view this is just a way to get overtime and weekend work out of people once things fall behind so they meet their commitments. I commit to do my work as best as i can but I can’t commit to work overtime because of issues that are often out of my control.
- sopooneo 7y ago
  That makes perfect sense. And I applaud your push against a practice that does seem to be pushing devs for unpaid overtime. You're right.
seer 7y ago
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.
- maxxxxx 7y ago
  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.
- itcheeze 7y ago
  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.
- mcv 7y ago
  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.

maxxxxx 7y ago

I understand that estimates are important and I give estimates. But recently in my company it’s fashionable to talk about “commitments” and I won’t give those. In my view this is just a way to get overtime and weekend work out of people once things fall behind so they meet their commitments. I commit to do my work as best as i can but I can’t commit to work overtime because of issues that are often out of my control.

sopooneo 7y ago
That makes perfect sense. And I applaud your push against a practice that does seem to be pushing devs for unpaid overtime. You're right.

seer 7y ago

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.

maxxxxx 7y ago
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.
itcheeze 7y ago
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.
mcv 7y ago
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.