4 ms·

We do this sometimes and it is interesting to see how big the range can be. The motivated, new developer gives a 3 for reasons while the senior who's been burne

We do this sometimes and it is interesting to see how big the range can be. The motivated, new developer gives a 3 for reasons while the senior who's been burned by the big ball of mud too many times gives a 13 and the PO somehow thinks this means it is an 8.. For me it is a wasted minute (times tickets), but you gotta pick your battles.

ponyous 5y ago
True. Our default is to go for higher estimation especially coming from a senior. 13 should be broken down tho.
- Oddskar 5y ago
  I know that this is a commonly held belief, but: why does it need to be broken down? Can a 13 not just be a 13?
  - ponyous 5y ago
    In our system it implies a major piece of work that can almost always be split down into multiple tickets that can usually be worked on in parallel. 2nd Splitting it in smaller parts forces you to examine all the parts and inner workings. Sometimes you will realise entirely different solution is needed, sometimes that there is an api call that will incur costs… and some of these things definitely have to be communicated to stakeholder, ideally before you spend significant times in development.
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.

ponyous 5y ago

True. Our default is to go for higher estimation especially coming from a senior. 13 should be broken down tho.

Oddskar 5y ago
I know that this is a commonly held belief, but: why does it need to be broken down? Can a 13 not just be a 13?
- ponyous 5y ago
  In our system it implies a major piece of work that can almost always be split down into multiple tickets that can usually be worked on in parallel. 2nd Splitting it in smaller parts forces you to examine all the parts and inner workings. Sometimes you will realise entirely different solution is needed, sometimes that there is an api call that will incur costs… and some of these things definitely have to be communicated to stakeholder, ideally before you spend significant times in development.

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.