4 ms·

At several companies I worked for, by using Scrum Points, it was always visible that the most experienced devs were able to regularly deliver a multiple (defini

by ratww 5y ago

At several companies I worked for, by using Scrum Points, it was always visible that the most experienced devs were able to regularly deliver a multiple (definitely around 10x) more points than interns and about 2x more than the average dev. Not a perfect metric by any means, of course, but definitely quantifiable and observable. Metrics for LOC and commits/PRs made also followed a similar pattern. Again, not perfect metrics, but it's what we had. Like another poster said [0], it's not really 10x the average, it's 10x when comparing best vs worst. [0] https://news.ycombinator.com/item?id=31074087 https://news.ycombinator.com/item?id=31074087

deleted 5y ago
[deleted]
torginus 5y ago
The problem with this metric is it can be gamed. We had something similar, and there was a huge 'meta' over who gets the shiny new features, and who has to fix the legacy code which was like Jenga, and a single misstep could break thousands of tests, and writing code was like playing minesweeper. The people who won the 'meta', got to be the most productive. Thing is, probably the guy who fixed a bug in the legacy hairball by writing 10 lines of code produced tons of value for the organization (those unit tests weren't for show, they were customer use cases), while the other one only produced some, if the fancy new feature got adopted.
Trasmatta 5y ago
Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Or estimating story points vastly differently than other members of the team? In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.
- ratww 5y ago
  > Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Your objections make no sense. If a story is easy but the number of points is not reflecting the ease, then the estimation is wrong, period. If there is someone on a team with such an estimation superpower so that they're able to know which tickets are easy, then just make this person estimate all the tickets. Problem solved. You either accept that someone is more productive, or you accept the estimation you performed is wrong by a factor of 2x. You can't have it both ways. > Or estimating story points vastly differently than other members of the team? In all the teams I worked the estimation was done by the entire team. If it's not being done by the whole team, then there's no real baseline to compare the work being done by two people, period. > In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures. The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint).
  - Trasmatta 5y ago
    > The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint). This doesn't make sense. If the measurement isn't expected to be accurate, how can it accurately inform you of the amount of work your team can do in a period of time? That's why I said it gives you an illusion of insight. There are so many external factors that points don't capture. And management frequently tries to turn them into very rigid timelines. It's a "garbage in, garbage out" problem that introduces extra stress for very little gain.
    - ratww 5y ago
      > If the measurement isn't expected to be accurate how can it accurately inform you of the amount of work your team can do in a period of time? Please don't misquote me just to push a point, I said "extremely accurate". They are an estimation. An estimation is NOT a deadline. It is not supposed to be extremely accurate. Here's what it says on the dictionary: "Estimation: A rough calculation of the value, number, quantity, or extent of something." It is supposed to have noise and sometimes even inconsistencies, but over longer periods it will work alright. Some stories will take too long, some too little, but in the long run it tends to even out. The more a team measures together, the closer it gets to being a very good predictor. Sometimes my team ends up the sprint with two or three small tasks left to finish, no biggie, sometimes we end up a day before and we're able to do a bit more. That's fine by us. > And management frequently tries to turn them into very rigid timelines Seems like none of your problems are because of Story Points. Story Points (at least in Scrum) are NOT for management. They are for developers to estimate how much they will pull from the backlog for a sprint. You have a process problem here. Also, if your management is trying to turn estimation into rigid timelines, you have a severe management problem that should be fixed. ...even though it seems that the person asking for perfect accuracy here is you. Story Points work fine for me. If they don't work for you, maybe you should ask what you're doing wrong and trying to fix the situation before throwing the baby away with the bathwater. Or maybe ask what I'm doing different. I'd be more than happy to help. What is not fine, however, is you claiming that something is shitty, inaccurate or source of frustration for you, just because you or your team aren't using it as intended. You clearly have an axe to grind with story points, but this says more about you than about the technique itself.

by ratww 5y ago

deleted 5y ago

[deleted]

torginus 5y ago

The problem with this metric is it can be gamed. We had something similar, and there was a huge 'meta' over who gets the shiny new features, and who has to fix the legacy code which was like Jenga, and a single misstep could break thousands of tests, and writing code was like playing minesweeper. The people who won the 'meta', got to be the most productive. Thing is, probably the guy who fixed a bug in the legacy hairball by writing 10 lines of code produced tons of value for the organization (those unit tests weren't for show, they were customer use cases), while the other one only produced some, if the fancy new feature got adopted.

Trasmatta 5y ago

Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Or estimating story points vastly differently than other members of the team? In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures.

ratww 5y ago
> Are you certain the devs getting 2x more points than the average dev weren't just consistently picking the easier stories? Your objections make no sense. If a story is easy but the number of points is not reflecting the ease, then the estimation is wrong, period. If there is someone on a team with such an estimation superpower so that they're able to know which tickets are easy, then just make this person estimate all the tickets. Problem solved. You either accept that someone is more productive, or you accept the estimation you performed is wrong by a factor of 2x. You can't have it both ways. > Or estimating story points vastly differently than other members of the team? In all the teams I worked the estimation was done by the entire team. If it's not being done by the whole team, then there's no real baseline to compare the work being done by two people, period. > In my experience, story points can be worse than no estimation. They give the illusion of insight, but in reality there's so much noise and inconsistency in point estimation, that they're almost never accurate measures. The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint).
- Trasmatta 5y ago
  > The point of story points is not to give extremely accurate measurements, but rather to inform you of the amount of work a team is able to do in a period of time (often a Sprint). This doesn't make sense. If the measurement isn't expected to be accurate, how can it accurately inform you of the amount of work your team can do in a period of time? That's why I said it gives you an illusion of insight. There are so many external factors that points don't capture. And management frequently tries to turn them into very rigid timelines. It's a "garbage in, garbage out" problem that introduces extra stress for very little gain.
  - ratww 5y ago
    > If the measurement isn't expected to be accurate how can it accurately inform you of the amount of work your team can do in a period of time? Please don't misquote me just to push a point, I said "extremely accurate". They are an estimation. An estimation is NOT a deadline. It is not supposed to be extremely accurate. Here's what it says on the dictionary: "Estimation: A rough calculation of the value, number, quantity, or extent of something." It is supposed to have noise and sometimes even inconsistencies, but over longer periods it will work alright. Some stories will take too long, some too little, but in the long run it tends to even out. The more a team measures together, the closer it gets to being a very good predictor. Sometimes my team ends up the sprint with two or three small tasks left to finish, no biggie, sometimes we end up a day before and we're able to do a bit more. That's fine by us. > And management frequently tries to turn them into very rigid timelines Seems like none of your problems are because of Story Points. Story Points (at least in Scrum) are NOT for management. They are for developers to estimate how much they will pull from the backlog for a sprint. You have a process problem here. Also, if your management is trying to turn estimation into rigid timelines, you have a severe management problem that should be fixed. ...even though it seems that the person asking for perfect accuracy here is you. Story Points work fine for me. If they don't work for you, maybe you should ask what you're doing wrong and trying to fix the situation before throwing the baby away with the bathwater. Or maybe ask what I'm doing different. I'd be more than happy to help. What is not fine, however, is you claiming that something is shitty, inaccurate or source of frustration for you, just because you or your team aren't using it as intended. You clearly have an axe to grind with story points, but this says more about you than about the technique itself.