4 ms·
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 dif
by 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.
- Trasmatta 5y ago> 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. > You clearly have an axe to grind with story points, but this says more about you than about the technique itself. This seems to be a very common occurrence whenever a criticism arises about agile or scrum -- "the issue isn't agile, it's how you're using it". At some point it's worth considering that there may be flaws in the techniques themselves, and its not always the fault of the people using those techniques. You've taken the several very short paragraphs I posted and started flinging some pretty baseless accusations at me. I'm not sure why you're intent on turning this into something more personal, but I'm not really interested in continuing the conversation anymore because of that.