> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work.
If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come to some consensus (the consensus includes things like "we need a lot more information before we can estimate" or "we need to break this up more").
If an individual is estimating the level of effort for work that could be given to any number of people then I think the estimation system needs improving.
I generally agree with the rest of your comment, though.
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.
> 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.
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..)
> 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.
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.
> If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high.
I think this is great advice in general, and I try to follow what I call the Scottie rule. Multiply your estimates by 4. That way you're a miracle worker! Or if you're like me, you might finish it on time.
I think there's some ego stuff going on though in planning sessions, and it seems bad estimates are rarely punished. And you can't really learn from it, since you always think "this time it's different."
If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come to some consensus (the consensus includes things like "we need a lot more information before we can estimate" or "we need to break this up more").
If an individual is estimating the level of effort for work that could be given to any number of people then I think the estimation system needs improving.
I generally agree with the rest of your comment, though.