3 ms·
This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's
by ohthehugemanate 6y ago
This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level.
TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out.
Personally I offer my customers to either pay by the week, or pay by extremely fixed scope with a 3 month definition period up front and a 50% buffer above the estimate. I stress that paying by the sprint lets them change objectives at any time, gives them an always-current report of how much "effort budget" they have left to work with, and guarantees they only pay for what they use. That felt like a risky move the first time I did it, but I never lost any business over it.
- zyber 6y agoI think that everyone still converts what-ever-unit used to time. For example, from one of my earlier jobs, we had "T-shirt"-size units, ranging from XS to XL. It took two weeks after introducing them until someone figured out that XS is two hours, so in a sprint you should be able to do $SPRINT_DURATION / 2 XS tasks. And then the person figured that S was equal to, say 4 hours and so on and we were back on square one. But we didn't estimate in concrete time units. /s