3 ms·

Story Point Estimation Doesn't Work

3 points by nickwritesit 2y ago

PaulHoule 2y ago
I feel that article is pretty weak. Personally I would rather estimate time than story points. I mean, I can look into my experience and say "I spent two weeks on that project" and if I'm using the issue tracker well I have a database of how much time I spent on each ticket I've worked on. Whereas I can't go back and say "I spent 37 story points on that one" because story points aren't real. If you wanted some artificial metric that was useful I'd also suggest https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point which is a structured way to determine how difficult a project is based on complexity. I worked on a system years ago where I had a framework that was well-designed for the things I was doing with it and the projects had little aspect of research to them so I could estimate small tasks in units of 10 minutes and add it up to a week of worth with 10% accuracy or so, spending maybe 10% of my time on project management but probably getting more gain than that because every morning I could refer to a detailed breakdown of what I had to do so I could start quickly out of the gate. The run-break-fix model of Livingston describes the kind of project that has a debugging or research component but it is highly probabilistic because it gives answers like: it might take 5-15 RBF cycles which will take 2 hours on average, which managers don't want to hear, but it could lead to interventions like "can we make that 2 hours 1.5 hours without increasing the number of cycles?" (which leads to the "path-not-taken" answer that it may well be cost effective to buy a $5000 computer for a dev and replace it every two years, when management hears carping about slow builds it should treat that as seriously as one might treat "I have cancer".)
taylodl 2y ago
The only point on which I agree with this article is each team should be able to use what works for them. I would also recommend, but not mandate, that teams do something akin to a sprint review (regular check-in with stakeholders), and backlog grooming. The cadence used for these activities can differ, depending on the team. The one-size-fits-all cookie cutter approach to Agile was only ever supposed to be used until the team figured out what works best for them. Fortune 500 companies started adopting Agile 15 years ago. The startups were doing it 10 years before then. It's kind of depressing seeing people still struggling with basic project management concepts. If your team is brand-new then sure, start off with your preferred methodology. Then adjust as needed. You might even do that if it's the same team and a brand-new project! The whole point of all this was there weren't supposed to be any hard and fast rules, just guidelines and recommendations. Do what works best for you!

3 points by nickwritesit 2y ago

I feel that article is pretty weak. Personally I would rather estimate time than story points. I mean, I can look into my experience and say "I spent two weeks on that project" and if I'm using the issue tracker well I have a database of how much time I spent on each ticket I've worked on. Whereas I can't go back and say "I spent 37 story points on that one" because story points aren't real. If you wanted some artificial metric that was useful I'd also suggest https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point which is a structured way to determine how difficult a project is based on complexity. I worked on a system years ago where I had a framework that was well-designed for the things I was doing with it and the projects had little aspect of research to them so I could estimate small tasks in units of 10 minutes and add it up to a week of worth with 10% accuracy or so, spending maybe 10% of my time on project management but probably getting more gain than that because every morning I could refer to a detailed breakdown of what I had to do so I could start quickly out of the gate. The run-break-fix model of Livingston describes the kind of project that has a debugging or research component but it is highly probabilistic because it gives answers like: it might take 5-15 RBF cycles which will take 2 hours on average, which managers don't want to hear, but it could lead to interventions like "can we make that 2 hours 1.5 hours without increasing the number of cycles?" (which leads to the "path-not-taken" answer that it may well be cost effective to buy a $5000 computer for a dev and replace it every two years, when management hears carping about slow builds it should treat that as seriously as one might treat "I have cancer".)

taylodl 2y ago

The only point on which I agree with this article is each team should be able to use what works for them. I would also recommend, but not mandate, that teams do something akin to a sprint review (regular check-in with stakeholders), and backlog grooming. The cadence used for these activities can differ, depending on the team. The one-size-fits-all cookie cutter approach to Agile was only ever supposed to be used until the team figured out what works best for them. Fortune 500 companies started adopting Agile 15 years ago. The startups were doing it 10 years before then. It's kind of depressing seeing people still struggling with basic project management concepts. If your team is brand-new then sure, start off with your preferred methodology. Then adjust as needed. You might even do that if it's the same team and a brand-new project! The whole point of all this was there weren't supposed to be any hard and fast rules, just guidelines and recommendations. Do what works best for you!