3 ms·

Last time I was in a team that did this, it was pretty useful. A wide range would spark a brief discussion (the senior would bring up the points that the junio

by 3np 5y ago

Last time I was in a team that did this, it was pretty useful. A wide range would spark a brief discussion (the senior would bring up the points that the junior is missing - yay knowledge sharing) and high estimates would usually result in breaking down. The key is to keep it short, if need be timebox.

throwanem 5y ago
That, and time estimates are output. Estimate by story points or T-shirt size, track how long tasks take to complete, and you can trivially derive a mapping from one to the other. Revise during implementation, too, if need be. Something that was estimated as a 3 and turns out to be a 1 gets re-pointed, and vice versa. This helps in all kinds of ways. Engineers don't have to think about time when estimating, which tends to make estimates freer and thus more accurate. PMs/POs don't have to deal with too much uncertainty, because the distribution of time to completion over a given estimate is right there. It's easier to know how much can fit into a given sprint, and as soon as all the tickets in a given epic are pointed, you can know about how long the epic will take to get done. Engineer time remains nonfungible, of course, but if the team is well balanced that seems to average out, and I don't (yet) know a better method of squaring a team's need for looseness with an organization's need for legibility.
- nickjj 5y ago
  > Estimate by story points [and] track how long tasks take to complete, and you can trivially derive a mapping from one to the other. I like this approach because time is such a weird thing to try and figure out beforehand. You either overpromise and look bad or over deliver but the thing you're delivering could get delayed because another team isn't ready. This other team will likely not be developers too, it could be a timeline imposed by the product team. Time still has importance tho because something can be easy but still take a decently long time. You could rate something 1 story point but it could still take 3 hours all-in from dev time to do because it involves making a very straight forward change to 8 services which entails maybe creating an epic Jira ticket to explain the situation and then 8 individual tickets (1 for each service repo) + 8 PRs + 8 code reviews + updating 8 release docs.
  - throwanem 5y ago
    For most purposes we don't try to be more granular than days, rounding up. When hours do matter, it's usually in a context where estimation isn't as important because whatever it is needs to be done ASAP.

by 3np 5y ago

throwanem 5y ago

That, and time estimates are output. Estimate by story points or T-shirt size, track how long tasks take to complete, and you can trivially derive a mapping from one to the other. Revise during implementation, too, if need be. Something that was estimated as a 3 and turns out to be a 1 gets re-pointed, and vice versa. This helps in all kinds of ways. Engineers don't have to think about time when estimating, which tends to make estimates freer and thus more accurate. PMs/POs don't have to deal with too much uncertainty, because the distribution of time to completion over a given estimate is right there. It's easier to know how much can fit into a given sprint, and as soon as all the tickets in a given epic are pointed, you can know about how long the epic will take to get done. Engineer time remains nonfungible, of course, but if the team is well balanced that seems to average out, and I don't (yet) know a better method of squaring a team's need for looseness with an organization's need for legibility.

nickjj 5y ago
> Estimate by story points [and] track how long tasks take to complete, and you can trivially derive a mapping from one to the other. I like this approach because time is such a weird thing to try and figure out beforehand. You either overpromise and look bad or over deliver but the thing you're delivering could get delayed because another team isn't ready. This other team will likely not be developers too, it could be a timeline imposed by the product team. Time still has importance tho because something can be easy but still take a decently long time. You could rate something 1 story point but it could still take 3 hours all-in from dev time to do because it involves making a very straight forward change to 8 services which entails maybe creating an epic Jira ticket to explain the situation and then 8 individual tickets (1 for each service repo) + 8 PRs + 8 code reviews + updating 8 release docs.
- throwanem 5y ago
  For most purposes we don't try to be more granular than days, rounding up. When hours do matter, it's usually in a context where estimation isn't as important because whatever it is needs to be done ASAP.