My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.
My favorite method of story pointing is throwing some chicken bones at a grease stain on the wall. It's as accurate as anything else.
"If it's not a 3, then it might be a 5. But if it's not a 5, that would mean it's an 8, and we can't have 8s. 8s are too much. You have to break it down more".
"What is 'too much'?"
"That's too many days of work".
"But I thought points weren't an estimate of time/hours/days, just a level of effort or complexity.".
"8s are too big"
"But... 8 is the best notion at this point. It's a complex problem. Maybe after working through the ticket, a natural break point will present itself and we can chunk it and make a second ticket with follow on work later. But right now, I can't see any split point".
"Well... you have to break it down first. Make this in to multiple tickets. The sprint starts tomorrow and we can't have 8s".
"How much time do I have to do the analysis to break it down?"
"None"
(If you suggested an 8, they'd look at you crazy and it would get back logged.)
The entire engineering org was measured on velocity. Every 2 weeks, at end of sprint, there would be a huge Slack posting with various stats for something like 6 or 7 teams. "85% completion! 5% are still in review. 10% of tasks were not even started!!"
Some managers would game the system. If a task wasn't done, they'd just mark it complete and open a ticket to finish it up next sprint (typically "integration testing for feature X" or "QA feature X".) One guy must've dragged his original 3 point ticket out for 4 sprints doing this. The "velocity" was meaningless.
It took about a year for disillusionment to settle in. Everybody seemed to come away from that document with a completely different interpretation and in most cases that interpretation was, "do exactly what we've always been doing that never worked, but add even more meetings on top of it."
One thing that no big-A "Agile" document has ever spelled out clearly is that the sort of agility can't work with fixed delivery dates. (Nor can any other software design methodology, but that won't stop "stakeholders" from insisting that because fixed delivery dates are Very Important, they're not just achievable but easy and you're just stupid).
I would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.