4 ms·

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional, so that estimation is about the team, not any person. And yes, when there's a task that one person happens to know most, people will often defer to them. But that in itself is educational, as the experienced dev explains why the given task is easy/hard. And every task is different, so the person you're deferring to will be different, and you still often get the two or three people who know the task best disagreeing until they hash it out, etc. And very often it's another person who can point out "well it would be that easy except three sprints ago I did x and so you'll now need to do y...". And of course plenty of tasks really are brand-new so everyone's figuring it out together. If you're really not having actual discussions around complexity in planning poker, then the facilitator/lead/manager might be doing it wrong. You do have to create an environment where people are expected to speak up and disagree, to demonstrate that this is welcomed and expected and rewarded, and not just some kind of checkbox exercise where the most senior dev gives their estimation and everyone agrees. This is also a reason why it's literally done with cards where everyone is forced to put their number on the table at the same time, so that you don't wind up with some senior person always going first and then everyone else just nodding and agreeing.

Gooblebrai 9mo ago
"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue) How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you? And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a task being a 3, but the task falls to a junior, they will take longer as is expected for his experience.
- crazygringo 9mo ago
  Here, you might want to read about it: https://www.atlassian.com/agile/project-management/estimation https://www.atlassian.com/agile/project-management/estimatio... Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points. > And then another matter is that points do not correlate to who later takes that work. Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.
  - Gooblebrai 9mo ago
    So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team? > An experienced senior dev might tend to deliver 30 points per sprint Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?
    - crazygringo 9mo ago
      > So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team? Basically, yup. It takes a few sprints to start to establish a meaningfully reliable sense of velocity, and the estimation accuracy is why planning poker takes a couple of hours of real discussion over feature complexity, rather than just a few minutes of superficial guesses. But the end result is a far more accurate ability to estimate what a team can reliably deliver in a sprint, and is really good at bringing stakeholders down to earth in terms of what can actually realistically be delivered. > Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. What's ironic? And no, it's not about "someone", it's about the the team. Different people on the team will be able to deliver different numbers of points depending on their skill, experience, etc. This is a major reason for not using time -- it actively recognizes that different people take different amounts of time, that things like sick days and meetings are taken into account, etc. > Isn't complexity directly proportional to uncertainty factors Yes, this is an explicit assumption of the Fibonnaci-style points usually used. > and therefore inversely proportional to confidence of time to completion? Yes, which is precisely why stories over a certain size are disallowed (the feature must be broken up into parts), and why sprints are measured in a very small number of weeks -- to avoid the accumulation of too much uncertainty.
Magmalgebra 9mo ago
> is in points not days I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing. I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.
- crazygringo 9mo ago
  > I've never met someone for whom points didn't eventually turn into a measurement of time The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to. The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310 https://news.ycombinator.com/item?id=46748310 The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here: https://www.atlassian.com/agile/project-management/estimation https://www.atlassian.com/agile/project-management/estimatio...
  - mitthrowaway2 9mo ago
    If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.
    - crazygringo 9mo ago
      Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision. The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size. I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, versus 11h +/- 3h. It's all just 5 points, or else 8 points, or else 13 points. It avoids discussion over any more precision than is actually reliably meaningful.
SoftTalker 9mo ago
I've never been involved in planning poker where everyone didn't converge on points = days at least in their own minds. "Hm, that would take me about a day, so that's one point."
- crazygringo 9mo ago
  Funny, I've never been on a team that did. Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story. For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've probably used 1/2 point stories a lot more... But this is why points are arbitrary. Each team decides whatever precise scale it wants. And it really depends on the type of work you're doing too -- whether the smallest stories tend to be things that are day-sized or things that are 2-hour sized.
  - SoftTalker 9mo ago
    Yeah we had half-point stories. Never remember getting as high as 20. I think we topped out at about 13 and those were usually split if they could be. It's been years since I did planning poker, sort of surprised to hear that it's still in use.
    - crazygringo 9mo ago
      > sort of surprised to hear that it's still in use. Why? It's not like it was some fad that didn't work. When things work, organizations tend to stick with them.

Gooblebrai 9mo ago

"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue) How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you? And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a task being a 3, but the task falls to a junior, they will take longer as is expected for his experience.

crazygringo 9mo ago
Here, you might want to read about it: https://www.atlassian.com/agile/project-management/estimation https://www.atlassian.com/agile/project-management/estimatio... Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points. > And then another matter is that points do not correlate to who later takes that work. Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.
- Gooblebrai 9mo ago
  So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team? > An experienced senior dev might tend to deliver 30 points per sprint Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?
  - crazygringo 9mo ago
    > So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team? Basically, yup. It takes a few sprints to start to establish a meaningfully reliable sense of velocity, and the estimation accuracy is why planning poker takes a couple of hours of real discussion over feature complexity, rather than just a few minutes of superficial guesses. But the end result is a far more accurate ability to estimate what a team can reliably deliver in a sprint, and is really good at bringing stakeholders down to earth in terms of what can actually realistically be delivered. > Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. What's ironic? And no, it's not about "someone", it's about the the team. Different people on the team will be able to deliver different numbers of points depending on their skill, experience, etc. This is a major reason for not using time -- it actively recognizes that different people take different amounts of time, that things like sick days and meetings are taken into account, etc. > Isn't complexity directly proportional to uncertainty factors Yes, this is an explicit assumption of the Fibonnaci-style points usually used. > and therefore inversely proportional to confidence of time to completion? Yes, which is precisely why stories over a certain size are disallowed (the feature must be broken up into parts), and why sprints are measured in a very small number of weeks -- to avoid the accumulation of too much uncertainty.

Magmalgebra 9mo ago

> is in points not days I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing. I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

crazygringo 9mo ago
> I've never met someone for whom points didn't eventually turn into a measurement of time The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to. The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310 https://news.ycombinator.com/item?id=46748310 The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here: https://www.atlassian.com/agile/project-management/estimation https://www.atlassian.com/agile/project-management/estimatio...
- mitthrowaway2 9mo ago
  If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.
  - crazygringo 9mo ago
    Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision. The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size. I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, versus 11h +/- 3h. It's all just 5 points, or else 8 points, or else 13 points. It avoids discussion over any more precision than is actually reliably meaningful.

SoftTalker 9mo ago

I've never been involved in planning poker where everyone didn't converge on points = days at least in their own minds. "Hm, that would take me about a day, so that's one point."

crazygringo 9mo ago
Funny, I've never been on a team that did. Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story. For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've probably used 1/2 point stories a lot more... But this is why points are arbitrary. Each team decides whatever precise scale it wants. And it really depends on the type of work you're doing too -- whether the smallest stories tend to be things that are day-sized or things that are 2-hour sized.
- SoftTalker 9mo ago
  Yeah we had half-point stories. Never remember getting as high as 20. I think we topped out at about 13 and those were usually split if they could be. It's been years since I did planning poker, sort of surprised to hear that it's still in use.
  - crazygringo 9mo ago
    > sort of surprised to hear that it's still in use. Why? It's not like it was some fad that didn't work. When things work, organizations tend to stick with them.