3 ms·

I don't even really understand your objections here. You're describing various tools that are useful in some situations to get the various developer and busines

I don't even really understand your objections here. You're describing various tools that are useful in some situations to get the various developer and business outcomes you want. Planning poker is useful for exposing different interpretations of a task from the perspective of multiple developers while trying to avoid group pressure or prejudiced outcomes. Spikes are tools that allow developers to explore a problem space and gain information about whether a proposed approach to a bigger problem is feasible and how much work might be involved. And story points are there to help the development team understand how much work they are able to get through in a period of time, to help improve estimates or targets that are useful for themselves and other parts of the business. I'm really sorry if you've had a bad time with this stuff, but none of it is unreasonable or particularly outlandish – and personally everything you've highlighted has been extremely useful to me as a developer. Like all tools they can be abused; the problem there is a broken organisation, and not a broken tool.

runawaybottle 7y ago
We can drill down. Let’s take moronic point poker. Let’s say I want to give a task to a new developer. He decides it’s tough and gives a high estimate. The rest of the devs give a lower estimate. Ok, what got achieved? We just pressured the new dev into what exactly? He gave his estimate. I don’t know, you’re all brilliant so fill me in. Most likely the new dev will lie under pressure and give a lower estimate. This is what really happens in real life. These mechanisms are so unrealistic. It’s ritual at this point.
- EamonnMR 7y ago
  So in this situation what the team learned is that the new developer isn't confident making the change and that if they pick up the task they should expect to help them get up to speed. This outcome is preferable to someone else estimating the task from on high and handing it over to someone who then spins their wheels and feels pressured to do it in an unrealistic amount of time. It's about visibility. It's also an opportunity to clarify what is expected-often different estimates come down to different interpretations of what the story is asking for!
- dcminter 7y ago
  What's supposed to happen is that you explore why some people think it's a low point task and others think it's a high point task. Typically you'll either find some rats nest of complexity that the low-pointers hadn't thought about/didn't know about: result? Go with the high estimate and the low pointers learn something. Or, you'll find that the high-pointer assumed something was in-scope that isn't: result? Go with the lower estimate and tighten up the story spec with some non-goals and maybe a link to pre-existing done-work. I've seen the version you describe, but only in dysfunctional companies. There's no helping those people but Scrum isn't the problem per se.
- matthewmacleod 7y ago
  Again, this means you have a broken team and not a broken tool. In the situation you describe, there are three possibilities: either the new dev makes a reasonable estimate and everybody else is wrong; the new dev is overestimating and more experienced devs are able to see that; or the new dev is not yet familiar with the point scale in use. In the first case, great! We expose some hidden complexity in a system that might be taken for granted by the existing developers, and this helps refine an estimate for the new team structure. In the second and more likely case, we can respond by tightening up the scope and specification of a task to make it clear what is in and out of scope. And in the third, we can work to make sure the new team member gets a feel for the sizing system in use, which tends to take a little bit of time when changing team makeup. These are not rituals and they are not unrealistic. They are specific tools aimed at solving real problems. It’s no surprise you have a bad experience if you are this aggressively dismissive of them.

runawaybottle 7y ago

We can drill down. Let’s take moronic point poker. Let’s say I want to give a task to a new developer. He decides it’s tough and gives a high estimate. The rest of the devs give a lower estimate. Ok, what got achieved? We just pressured the new dev into what exactly? He gave his estimate. I don’t know, you’re all brilliant so fill me in. Most likely the new dev will lie under pressure and give a lower estimate. This is what really happens in real life. These mechanisms are so unrealistic. It’s ritual at this point.

EamonnMR 7y ago
So in this situation what the team learned is that the new developer isn't confident making the change and that if they pick up the task they should expect to help them get up to speed. This outcome is preferable to someone else estimating the task from on high and handing it over to someone who then spins their wheels and feels pressured to do it in an unrealistic amount of time. It's about visibility. It's also an opportunity to clarify what is expected-often different estimates come down to different interpretations of what the story is asking for!
dcminter 7y ago
What's supposed to happen is that you explore why some people think it's a low point task and others think it's a high point task. Typically you'll either find some rats nest of complexity that the low-pointers hadn't thought about/didn't know about: result? Go with the high estimate and the low pointers learn something. Or, you'll find that the high-pointer assumed something was in-scope that isn't: result? Go with the lower estimate and tighten up the story spec with some non-goals and maybe a link to pre-existing done-work. I've seen the version you describe, but only in dysfunctional companies. There's no helping those people but Scrum isn't the problem per se.
matthewmacleod 7y ago
Again, this means you have a broken team and not a broken tool. In the situation you describe, there are three possibilities: either the new dev makes a reasonable estimate and everybody else is wrong; the new dev is overestimating and more experienced devs are able to see that; or the new dev is not yet familiar with the point scale in use. In the first case, great! We expose some hidden complexity in a system that might be taken for granted by the existing developers, and this helps refine an estimate for the new team structure. In the second and more likely case, we can respond by tightening up the scope and specification of a task to make it clear what is in and out of scope. And in the third, we can work to make sure the new team member gets a feel for the sizing system in use, which tends to take a little bit of time when changing team makeup. These are not rituals and they are not unrealistic. They are specific tools aimed at solving real problems. It’s no surprise you have a bad experience if you are this aggressively dismissive of them.