5 ms·

One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to mak

by cbanek 6y ago

One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people become the bottlenecks and you aren't sure what to give the people that aren't so good. 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. And there's this feeling that by spreading out the work over a whole team, that the bus factor is increased and it is worth it to have everyone understand everything about everything. But there is a definite tax in terms of productivity, speed, and quality.

vosper 6y ago
> 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.
- cbanek 6y ago
  > 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."
- emeraldd 6y ago
  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.
bitwize 6y ago
I've said it before: one of the goals of Agile methodologies as sold to management is the promise of emulating a good developer with a redundant array of mediocre developers. Good developers can produce good work fast. They can take feedback on an iteration and turn it into working code for the next iteration quickly. But they're unreliable -- prone to getting cranky or bored -- and they're a single point of failure: If they die or quit because they got too cranky or bored, million dollar projects can be put in jeopardy. But by spreading the work out over a team and making them collectively responsible for the code, and by keeping them constantly in communication, it is hoped, you can take advantage of their cumulative brainpower to get good developer quality and turn around time while smoothing over the reliability issues because any one developer is fungible with the rest. It is hoped, that is. Reality is usually quite different...

by cbanek 6y ago

vosper 6y ago

> 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.

cbanek 6y ago
> 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."
emeraldd 6y ago
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.

bitwize 6y ago

I've said it before: one of the goals of Agile methodologies as sold to management is the promise of emulating a good developer with a redundant array of mediocre developers. Good developers can produce good work fast. They can take feedback on an iteration and turn it into working code for the next iteration quickly. But they're unreliable -- prone to getting cranky or bored -- and they're a single point of failure: If they die or quit because they got too cranky or bored, million dollar projects can be put in jeopardy. But by spreading the work out over a team and making them collectively responsible for the code, and by keeping them constantly in communication, it is hoped, you can take advantage of their cumulative brainpower to get good developer quality and turn around time while smoothing over the reliability issues because any one developer is fungible with the rest. It is hoped, that is. Reality is usually quite different...