How do you measure “effort”? What is a unit of effort? How do I know whether a task is a 2 or a 3 efforts? What is the actual difference there? “It’s the complexity, the work load, and the risks and uncertainties”. Ok… but are those things truly measurable? Are they equally weighted? What complexity takes it from a 2 to a 3? Are we just going off of vibes here? Does a 2 to me mean the same thing as a 3 to you?
Why would effort scale with a fibonacci scale? How can non subject matter experts estimate effort on a task they aren’t familiar with from a Jira Card Description? Do you measure effort of dev work and qa work? Or do you separate those things? If dev work is 3 story points and qa work is 3 story points, what is the combined effort on the fibonacci scale since there is no 6? Or is it just a 3 between them because the dev and qa work are assumed for all tickets?
But also, “It’s not about time, it’s about effort”. OK then why are we measuring velocity in story points per 2 week sprint. And we have a story point capacity per two week sprint. And we adjust that capacity directly against the number of days people are taking off this sprint. So it’s absolutely, positively, not a measure of the amount of time needed. But we do allot story points relative to manhours available.
sigh. I wonder if I’d rather just have bullshit deadlines then play another pointless game of planning poker with only half of my team barely participating and the scrum master trying to get enthusiastic consensus on a scale that is, at best, about how you feel about a task you are probably just learning about and don’t fully understand.
So much of agile “process” gets so close to the point while still missing it, it’s infuriating. Absolutely 100% agree that story points are mostly meaningless, but story pointing shouldn’t be the point of backlog refinement. The point should be to discuss upcoming work, clarify things, ask questions, make sure everyone’s on the same page, moving in the same direction, and making sure all the work is accounted for. Story points can be a nice punctuation to all that discussion and planning effort, but for the most part it’s nothing more than a contrivance to satisfy management’s boner for tracking useless metrics.
I totally agree about story points being bollocks. Their supposed justification is that you can measure velocity by seeing how many story points you do per month, but that only works if there’s no feedback from velocity to story point estimation which is obviously not the case.
So in practice they just become a stupid proxy for time. “1 story point is an hour right?”
The Fibonacci thing makes some sense to me though - it is a way of suggesting that bigger estimates are less accurate.
Of course it would be much better if you could actually put an accuracy directly into Jira or whatever (e.g. 10-30 hours), but that would apparently be way too complicated. You could also get that data fairly nicely from planning poker (which I also think is pretty good, but you throw away all the information about uncertainty that you just spent ages discovering!)
Story points are such entire bullshit.
How do you measure “effort”? What is a unit of effort? How do I know whether a task is a 2 or a 3 efforts? What is the actual difference there? “It’s the complexity, the work load, and the risks and uncertainties”. Ok… but are those things truly measurable? Are they equally weighted? What complexity takes it from a 2 to a 3? Are we just going off of vibes here? Does a 2 to me mean the same thing as a 3 to you?
Why would effort scale with a fibonacci scale? How can non subject matter experts estimate effort on a task they aren’t familiar with from a Jira Card Description? Do you measure effort of dev work and qa work? Or do you separate those things? If dev work is 3 story points and qa work is 3 story points, what is the combined effort on the fibonacci scale since there is no 6? Or is it just a 3 between them because the dev and qa work are assumed for all tickets?
But also, “It’s not about time, it’s about effort”. OK then why are we measuring velocity in story points per 2 week sprint. And we have a story point capacity per two week sprint. And we adjust that capacity directly against the number of days people are taking off this sprint. So it’s absolutely, positively, not a measure of the amount of time needed. But we do allot story points relative to manhours available.
sigh. I wonder if I’d rather just have bullshit deadlines then play another pointless game of planning poker with only half of my team barely participating and the scrum master trying to get enthusiastic consensus on a scale that is, at best, about how you feel about a task you are probably just learning about and don’t fully understand.
So much of agile “process” gets so close to the point while still missing it, it’s infuriating. Absolutely 100% agree that story points are mostly meaningless, but story pointing shouldn’t be the point of backlog refinement. The point should be to discuss upcoming work, clarify things, ask questions, make sure everyone’s on the same page, moving in the same direction, and making sure all the work is accounted for. Story points can be a nice punctuation to all that discussion and planning effort, but for the most part it’s nothing more than a contrivance to satisfy management’s boner for tracking useless metrics.
I totally agree about story points being bollocks. Their supposed justification is that you can measure velocity by seeing how many story points you do per month, but that only works if there’s no feedback from velocity to story point estimation which is obviously not the case.
So in practice they just become a stupid proxy for time. “1 story point is an hour right?”
The Fibonacci thing makes some sense to me though - it is a way of suggesting that bigger estimates are less accurate.
Of course it would be much better if you could actually put an accuracy directly into Jira or whatever (e.g. 10-30 hours), but that would apparently be way too complicated. You could also get that data fairly nicely from planning poker (which I also think is pretty good, but you throw away all the information about uncertainty that you just spent ages discovering!)