5 ms·

How do you propose stopping estimates from becoming commitments? Genuinely asking because I struggle to not do this as a manager.

by wsostt 4y ago

dd444fgdfg 4y ago
Imagine a timeline from left to right. On the left is where there's the least knowledge about the project, and on the right the most (when the project is done). Estimates are made at the far left, when the developers know the least. So as you move along the timeline and more knowledge is discovered, you need to reset expectations frequently.
- jtdev 4y ago
grayclhn 4y ago
If you need to actually make meaningful commitments, you need to track how long stories/projects/whatever actually take, and use the data to make a prediction. Subjective “estimates” can be an input, but they’re basically guesses.
mkoubaa 4y ago
It starts understanding the meaning of the word "estimate" in the English language.
CSMastermind 4y ago
Part of the answer is don't give estimates when you can help it. I've had a lot of success just having a roadmap and telling people, this is what we're working on now, this is what's next in the pipeline, and here's where you can track our progress for yourself. Another tip I have is to constrain estimates to board timescales like Q3 or H2 when you are able to (there are certain business scenarios that do require estimates). A similar thing you can do is give your "estimate" not in the form of a date but in the form of ambiguity and scale. Or better yet just state the factors that would go into giving an estimate without offering one. Lastly I'd suggest just not shying away from commitments but making them about effort not outcome. "I have 3 developers working on this full time and it will be their sole focus until we ship. Nothing you say or do is going to get this feature launched any faster than it's going to be now."
- groby_b 4y ago
  Given that other skills work at different time scales, this doesn't always work. Two of the most common examples: 1) You work anywhere near money and commerce. The existence of Black Friday and the following weeks of shopping frenzy ensure that you will always be very aware what date Thanksgiving is. And that everybody will need timelines especially close around that date. 2) You work on a product that also gets marketing. There's a lead time of several months for a good marketing effort with coordinated press, and you really don't want to have all that lined up and then blow your timeline. If you can help it, at all, learn estimation. Sure, don't share it if your management is incompetent at handling estimations, but the ability to predict a timeline with error bars is extremely useful. Practice by yourself. You'll be happy you did. (And if your estimates are reasonably correct and you have decent management, you experience magic like "OK, then let's cut scope" or "Is there anybody who'd accelerate this if they were on your team". With a heavy nod to the fact that there are not enough managers who can pull off that magic - because they never understood estimation)
closeparen 4y ago
I think the demand for timeline commitments comes from a worry that otherwise the request will never be done, or that it will languish in the queue behind less important things. Where possible, I try to frame my relationship with my stakeholders in terms of their priority order for their requests of me, and to demonstrate consistent progress on that stream. Thus, we have an understanding that the things they ask for do get done, and they want a particular one done sooner, they can move it up in the stack rank.
- doctor_eval 4y ago
  Could not agree more with this, and it can scale to small teams. Establishing consistent “velocity” and demonstrating progress is way more important than estimating individual features.
doctor_eval 4y ago
You could start by not doing estimates? Instead, take an educated guess of the complexity of the problem and then ask how long the enterprise is willing to commit to implementing it. Estimates are just a way of delegating responsibility downwards. The organisation is rarely asked to estimate how much a feature is worth, despite this being probably the more important factor.
ohthehugemanate 4y ago
If you run estimates with an abstracted unit of measurement ("ideal developer days," "story points," "cups of coffee," "tshirt sizes" etc), then you get three important super powers for this. 1) Your long range timelines come with a specific, quantified error margin. It's no longer "we'll be done by December 15," it's "we'll be done by December 15 with a 95% confidence, or January 15 with a 99% confidence." (Not to mention, those CIs are real and so your estimates have a very high degree of certainty) 2) your estimates have explicit conditions built in, most notably "based on our current understanding of the work." The door is already explicitly open to respond to feature requests, changes, or just new information with an estimate change. 3) Your estimate adjusts very quickly, so the conversations from #2 are also clear. You can make commitments under those circumstances a lot more easily.
- azemetre 4y ago
  Apparently if you do zero estimating (or just count the amount of stories), it makes ZERO difference when calculating your cumulative-flow diagram. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms Money segment is at the 26m15s mark. The wasted effort of trying to estimate stories provides zero business value in this context.
  - ohthehugemanate 4y ago
    Yes, you can do the same math if your stories are consistently sized, or if you have a sufficiently large data set. All you need is a consistent unit that is related to complexity, risk, and time. The less precise that relation, the larger sample size you need. For many teams who get requests from external stakeholders in widely varied technical environments - ie consulting, often - estimation is functionally just a conversion process to a consistent unit. But you're absolutely right that for some teams the stories themselves are a good enough unit.
- mgkimsal 4y ago
  No idea why "story points" or "cups of coffee" or "shirt sizes" have much relation to time. I mean... I get it, but... many places I've worked also go to pains to say "this isn't hours, we're just estimating relative complexity". But plenty of issues are extremely complex, but may only take a few days, vs some items which are less complex, but larger (touching a number of files, or screens, etc). With that rubric, 8 story points might take 3-4 days of focused concentration, and 3 story points might take 5-6 days of less focused but more brute force. Nowhere I've worked accepts that as legitimate, and want to redefine the language in to something that approximates time. So... why not just estimate days or hours anyway? Both an estimate of "large shirt" and "30 hours" can have 'explicit conditions built in'. This will be 30 hours with my current understanding of the request. If that understanding changes, 30 hours will change. I don't think you need 'shirts' for that? I can easily make commitments if the people I'm committing to are fine with a change in the dates. That's a big 'if', and not one that plays out positively most times. This is the rub, because most places I've been at, the commitment ends up being treated as a deadline, because... that seems to be how people work. "Dec 15 with 90% confidence" becomes "dec 15" and other parties start making plans and decisions based on "dec 15" without any consultation or being looped in to the process, and when 'dec 15' has to become 'jan 10', many many people are impacted and generally upset.
mch82 4y ago
One thing to do is to show your estimates as distribution curves instead of averages. It can be helpful to choose estimates from a Fibonacci scale. Set the pessimistic estimate high enough that it’ll rarely be missed. Edit: I change the units based on how far out I’m estimating. If I’m estimating the next six weeks, I’ll use hours. If I’m estimating a roadmap I’ll use weeks. The numbers get large quickly (1 2 3 5 8 13 21 34 55 89 144). It’s rare you’ll find yourself planning farther than 2 years out (104 weeks). As you work, keep updating the estimated time remaining. If the initial estimate for a task is an 8 (between 5 and 13), keep reporting 8 until your estimate falls below 8, then report 5 (between 3 and 8). Avoid reporting intermediate values like 7.

How do you propose stopping estimates from becoming commitments? Genuinely asking because I struggle to not do this as a manager.

by wsostt 4y ago

How do you propose stopping estimates from becoming commitments? Genuinely asking because I struggle to not do this as a manager.

dd444fgdfg 4y ago

Imagine a timeline from left to right. On the left is where there's the least knowledge about the project, and on the right the most (when the project is done). Estimates are made at the far left, when the developers know the least. So as you move along the timeline and more knowledge is discovered, you need to reset expectations frequently.

jtdev 4y ago

grayclhn 4y ago

If you need to actually make meaningful commitments, you need to track how long stories/projects/whatever actually take, and use the data to make a prediction. Subjective “estimates” can be an input, but they’re basically guesses.

mkoubaa 4y ago

It starts understanding the meaning of the word "estimate" in the English language.

CSMastermind 4y ago

Part of the answer is don't give estimates when you can help it. I've had a lot of success just having a roadmap and telling people, this is what we're working on now, this is what's next in the pipeline, and here's where you can track our progress for yourself. Another tip I have is to constrain estimates to board timescales like Q3 or H2 when you are able to (there are certain business scenarios that do require estimates). A similar thing you can do is give your "estimate" not in the form of a date but in the form of ambiguity and scale. Or better yet just state the factors that would go into giving an estimate without offering one. Lastly I'd suggest just not shying away from commitments but making them about effort not outcome. "I have 3 developers working on this full time and it will be their sole focus until we ship. Nothing you say or do is going to get this feature launched any faster than it's going to be now."

groby_b 4y ago
Given that other skills work at different time scales, this doesn't always work. Two of the most common examples: 1) You work anywhere near money and commerce. The existence of Black Friday and the following weeks of shopping frenzy ensure that you will always be very aware what date Thanksgiving is. And that everybody will need timelines especially close around that date. 2) You work on a product that also gets marketing. There's a lead time of several months for a good marketing effort with coordinated press, and you really don't want to have all that lined up and then blow your timeline. If you can help it, at all, learn estimation. Sure, don't share it if your management is incompetent at handling estimations, but the ability to predict a timeline with error bars is extremely useful. Practice by yourself. You'll be happy you did. (And if your estimates are reasonably correct and you have decent management, you experience magic like "OK, then let's cut scope" or "Is there anybody who'd accelerate this if they were on your team". With a heavy nod to the fact that there are not enough managers who can pull off that magic - because they never understood estimation)

closeparen 4y ago

I think the demand for timeline commitments comes from a worry that otherwise the request will never be done, or that it will languish in the queue behind less important things. Where possible, I try to frame my relationship with my stakeholders in terms of their priority order for their requests of me, and to demonstrate consistent progress on that stream. Thus, we have an understanding that the things they ask for do get done, and they want a particular one done sooner, they can move it up in the stack rank.

doctor_eval 4y ago
Could not agree more with this, and it can scale to small teams. Establishing consistent “velocity” and demonstrating progress is way more important than estimating individual features.

doctor_eval 4y ago

You could start by not doing estimates? Instead, take an educated guess of the complexity of the problem and then ask how long the enterprise is willing to commit to implementing it. Estimates are just a way of delegating responsibility downwards. The organisation is rarely asked to estimate how much a feature is worth, despite this being probably the more important factor.

ohthehugemanate 4y ago

If you run estimates with an abstracted unit of measurement ("ideal developer days," "story points," "cups of coffee," "tshirt sizes" etc), then you get three important super powers for this. 1) Your long range timelines come with a specific, quantified error margin. It's no longer "we'll be done by December 15," it's "we'll be done by December 15 with a 95% confidence, or January 15 with a 99% confidence." (Not to mention, those CIs are real and so your estimates have a very high degree of certainty) 2) your estimates have explicit conditions built in, most notably "based on our current understanding of the work." The door is already explicitly open to respond to feature requests, changes, or just new information with an estimate change. 3) Your estimate adjusts very quickly, so the conversations from #2 are also clear. You can make commitments under those circumstances a lot more easily.

azemetre 4y ago
Apparently if you do zero estimating (or just count the amount of stories), it makes ZERO difference when calculating your cumulative-flow diagram. https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=QVBlnCTu9Ms Money segment is at the 26m15s mark. The wasted effort of trying to estimate stories provides zero business value in this context.
- ohthehugemanate 4y ago
  Yes, you can do the same math if your stories are consistently sized, or if you have a sufficiently large data set. All you need is a consistent unit that is related to complexity, risk, and time. The less precise that relation, the larger sample size you need. For many teams who get requests from external stakeholders in widely varied technical environments - ie consulting, often - estimation is functionally just a conversion process to a consistent unit. But you're absolutely right that for some teams the stories themselves are a good enough unit.
mgkimsal 4y ago
No idea why "story points" or "cups of coffee" or "shirt sizes" have much relation to time. I mean... I get it, but... many places I've worked also go to pains to say "this isn't hours, we're just estimating relative complexity". But plenty of issues are extremely complex, but may only take a few days, vs some items which are less complex, but larger (touching a number of files, or screens, etc). With that rubric, 8 story points might take 3-4 days of focused concentration, and 3 story points might take 5-6 days of less focused but more brute force. Nowhere I've worked accepts that as legitimate, and want to redefine the language in to something that approximates time. So... why not just estimate days or hours anyway? Both an estimate of "large shirt" and "30 hours" can have 'explicit conditions built in'. This will be 30 hours with my current understanding of the request. If that understanding changes, 30 hours will change. I don't think you need 'shirts' for that? I can easily make commitments if the people I'm committing to are fine with a change in the dates. That's a big 'if', and not one that plays out positively most times. This is the rub, because most places I've been at, the commitment ends up being treated as a deadline, because... that seems to be how people work. "Dec 15 with 90% confidence" becomes "dec 15" and other parties start making plans and decisions based on "dec 15" without any consultation or being looped in to the process, and when 'dec 15' has to become 'jan 10', many many people are impacted and generally upset.

mch82 4y ago

One thing to do is to show your estimates as distribution curves instead of averages. It can be helpful to choose estimates from a Fibonacci scale. Set the pessimistic estimate high enough that it’ll rarely be missed. Edit: I change the units based on how far out I’m estimating. If I’m estimating the next six weeks, I’ll use hours. If I’m estimating a roadmap I’ll use weeks. The numbers get large quickly (1 2 3 5 8 13 21 34 55 89 144). It’s rare you’ll find yourself planning farther than 2 years out (104 weeks). As you work, keep updating the estimated time remaining. If the initial estimate for a task is an 8 (between 5 and 13), keep reporting 8 until your estimate falls below 8, then report 5 (between 3 and 8). Avoid reporting intermediate values like 7.