6 ms·

Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps

Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.

lazyasciiart 3y ago
Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.
- crazygringo 3y ago
  Then that's not agile. The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity. If you're not doing that, then you're not even in any conversation about agile/scrum.
kqr 3y ago
I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?
- irjustin 3y ago
  nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points. By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints. Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.
  - mongol 3y ago
    Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.
    - irjustin 3y ago
      As mentioned, it's technically arbitrary, so you just need to get used to how your org does it. There's no right or wrong as long as your org agrees on the value of those points... sort of like bitcoin, ha ha (cries in BTC).
    - hgsgm 3y ago
      You didn't say how long a sprint is nor how large your team is, which makes me suspect that you don't handle measurements well in general.
  - kqr 3y ago
    Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!
    - Scarblac 3y ago
      The main point of points is that they are not supposed to be equivalent to x amount of time. They're supposed to represent a measure of complexity. How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on. They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...
      - re-thc 3y ago
- Double_a_92 3y ago
  Theoretically it's arbitrary numbers. Then a factor specifically calculated for your team gets applied to it to turn it into hours or days. But in reality it's ideal hours or ideal days. The 8 and 13 come from the fibonacci sequence.

lazyasciiart 3y ago

Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.

crazygringo 3y ago
Then that's not agile. The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity. If you're not doing that, then you're not even in any conversation about agile/scrum.

kqr 3y ago

I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?

irjustin 3y ago
nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points. By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints. Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.
- mongol 3y ago
  Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.
  - irjustin 3y ago
    As mentioned, it's technically arbitrary, so you just need to get used to how your org does it. There's no right or wrong as long as your org agrees on the value of those points... sort of like bitcoin, ha ha (cries in BTC).
  - hgsgm 3y ago
    You didn't say how long a sprint is nor how large your team is, which makes me suspect that you don't handle measurements well in general.
- kqr 3y ago
  Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!
  - Scarblac 3y ago
    The main point of points is that they are not supposed to be equivalent to x amount of time. They're supposed to represent a measure of complexity. How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on. They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...
    - re-thc 3y ago
Double_a_92 3y ago
Theoretically it's arbitrary numbers. Then a factor specifically calculated for your team gets applied to it to turn it into hours or days. But in reality it's ideal hours or ideal days. The 8 and 13 come from the fibonacci sequence.