5 ms·

I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefor

I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature set but instead changing requirements all the time.

Aeolun 7y ago
Changing requirements is fine, as long as they recognize that stuff like that impacts the schedule. Generally they don’t though.
sopooneo 7y ago
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.
fabioborellini 7y ago
Even better is being told to commit by the Scrum Jesus (who does not even try to understand the business domain or engineering issues, since he's getting hired for being the Scrum Jesus) to stories with no one available for even defining or discussing them. Our story might have been just a word someone saw at a trade fair. Then, two weeks later, being asked why I did not complete what I committed to.
- nicwolff 7y ago
  In that situation I've gotten a lot of mileage (and quiet amusement) from pointing out that Scrum dropped the term "commitment" for "forecast" in 2011. Scrum Jesus has no defense against Scrum itself! "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint." https://scrumguides.org/revisions.html https://scrumguides.org/revisions.html, "Changes between 2010 and 2011 Scrum Guides"

Aeolun 7y ago

Changing requirements is fine, as long as they recognize that stuff like that impacts the schedule. Generally they don’t though.

sopooneo 7y ago

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.

fabioborellini 7y ago

Even better is being told to commit by the Scrum Jesus (who does not even try to understand the business domain or engineering issues, since he's getting hired for being the Scrum Jesus) to stories with no one available for even defining or discussing them. Our story might have been just a word someone saw at a trade fair. Then, two weeks later, being asked why I did not complete what I committed to.

nicwolff 7y ago
In that situation I've gotten a lot of mileage (and quiet amusement) from pointing out that Scrum dropped the term "commitment" for "forecast" in 2011. Scrum Jesus has no defense against Scrum itself! "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint." https://scrumguides.org/revisions.html https://scrumguides.org/revisions.html, "Changes between 2010 and 2011 Scrum Guides"