3 ms·

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and every

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

dragonwriter 6y ago
> Honestly, I've never found story pointing exercises to result in anything resembling reality. IIRC, story points are a replacement for detailed hour estimates that were created specifically because of research dating back through the 1940s shows clearly that estimates of original intellectual work of any detail are essentially impossible; story points are literally throwing in the towel on that issue and wasting less time chasing something you aren't going to get. With tracking of velocity and history you get better numbers with story points than when people try to estimate in hours, because people are better at rough relative size estimates than detailed estimates, but that's a marginal improvement. The big win is you spend less time chasing false precision with them.
- emeraldd 6y ago
  That's reasonable ... The times I've worked with hour based estimates, we were assigning tickets to people up front and there always had to be a bit of a scaling factor based on who was doing the work. (mostly relative to their skill level and how familiar they were with a particular piece of code). There are at least a couple of no-nos for scrum style processes in there. Still, I find it more useful to look at the number of tickets and what's actually being done in them and ignore the point/hour values when trying to come up with what's a good break down of work for a sprint. The point values are just too opaque to convey anything that can be substantively predictive. (At least for me..)
curryst 6y ago
> Honestly, I've never found story pointing exercises to result in anything resembling reality. I've never found story pointing exercises to provide anything meaningful. Goodhart's law in action; you either ignore the story points, making them useless, or you use them to estimate productivity, causing people to game them. I understand that gauging velocity and individual contributions is important, I just think story points or work estimates are a bad way to do it in the context of sprints. An individual task, or even a sprint, is too micro to get any decent measure out of. I much more strongly prefer evaluations based on longer milestones (monthly or quarterly). Someone being low on story points for a sprint means nothing without a lot of context on why. Someone missing a milestone on a month or quarter long project is much more indicative of a problem, because they've had enough time to ask for help, or to smooth out bursty progress.
- emeraldd 6y ago
  This is actually kind of disturbing to me... I didn't think story points were supposed to be used as this kind of metric. Linking performance to story points seems like a complete misapplication of something that is supposedly meant to help determine how much work can be put in a sprint.

dragonwriter 6y ago

> Honestly, I've never found story pointing exercises to result in anything resembling reality. IIRC, story points are a replacement for detailed hour estimates that were created specifically because of research dating back through the 1940s shows clearly that estimates of original intellectual work of any detail are essentially impossible; story points are literally throwing in the towel on that issue and wasting less time chasing something you aren't going to get. With tracking of velocity and history you get better numbers with story points than when people try to estimate in hours, because people are better at rough relative size estimates than detailed estimates, but that's a marginal improvement. The big win is you spend less time chasing false precision with them.

emeraldd 6y ago
That's reasonable ... The times I've worked with hour based estimates, we were assigning tickets to people up front and there always had to be a bit of a scaling factor based on who was doing the work. (mostly relative to their skill level and how familiar they were with a particular piece of code). There are at least a couple of no-nos for scrum style processes in there. Still, I find it more useful to look at the number of tickets and what's actually being done in them and ignore the point/hour values when trying to come up with what's a good break down of work for a sprint. The point values are just too opaque to convey anything that can be substantively predictive. (At least for me..)

curryst 6y ago

> Honestly, I've never found story pointing exercises to result in anything resembling reality. I've never found story pointing exercises to provide anything meaningful. Goodhart's law in action; you either ignore the story points, making them useless, or you use them to estimate productivity, causing people to game them. I understand that gauging velocity and individual contributions is important, I just think story points or work estimates are a bad way to do it in the context of sprints. An individual task, or even a sprint, is too micro to get any decent measure out of. I much more strongly prefer evaluations based on longer milestones (monthly or quarterly). Someone being low on story points for a sprint means nothing without a lot of context on why. Someone missing a milestone on a month or quarter long project is much more indicative of a problem, because they've had enough time to ask for help, or to smooth out bursty progress.

emeraldd 6y ago
This is actually kind of disturbing to me... I didn't think story points were supposed to be used as this kind of metric. Linking performance to story points seems like a complete misapplication of something that is supposedly meant to help determine how much work can be put in a sprint.