4 ms·

If you have not yet read the Scrum Guide, please read it. It does not tell you in detail how to do Scrum, but the framework is there. https://scrumguides.org/sc

If you have not yet read the Scrum Guide, please read it. It does not tell you in detail how to do Scrum, but the framework is there. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html 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.

jacobyoder 4y ago
My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects). "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".
- commandlinefan 4y ago
  > "You have to break it down more" "How much time do I have to do the analysis to break it down?" "None"
- deathanatos 4y ago
  And every ticket is complex, and the PM is annoyed that every ticket is being faithfully marked as such. But they balk at taking the time to try to plan out that high level goal to enough extend that we can break the ticket apart into smaller pieces that make sense, or just make it an epic because it is one and add tickets to it as we figure out how we're going to implement $todays_insanity_from_higher_up…
- icedchai 4y ago
  I experienced similar at a previous company. Everything was a 1, 2, or 3. If it was a 5, the "scrum master" got a frowny-face. "Guys, can we break this down more??" Then a 15 minute discussion would ensue. That was literally the person's only contribution. (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.
commandlinefan 4y ago
I remember reading the agile manifesto around '99 or so (back then it was called XP, "extreme progrmming") and then, after having worked in software for going on 10 years, it was a breath of fresh air. I couldn't believe that logical, rational, sane principles of software development were not just being proposed by influential voices but were actually being considered by managers. 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).
- deleted 4y ago
  [deleted]
- 0xbadcafebee 4y ago
  I mean, Agile just can't work at all, because it conceives of only one part of a business without considering all the other parts. I would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.

jacobyoder 4y ago

My overarching experience with 'agile story points' (paraphrased combination between multiple teams/projects). "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".

commandlinefan 4y ago
> "You have to break it down more" "How much time do I have to do the analysis to break it down?" "None"
deathanatos 4y ago
And every ticket is complex, and the PM is annoyed that every ticket is being faithfully marked as such. But they balk at taking the time to try to plan out that high level goal to enough extend that we can break the ticket apart into smaller pieces that make sense, or just make it an epic because it is one and add tickets to it as we figure out how we're going to implement $todays_insanity_from_higher_up…
icedchai 4y ago
I experienced similar at a previous company. Everything was a 1, 2, or 3. If it was a 5, the "scrum master" got a frowny-face. "Guys, can we break this down more??" Then a 15 minute discussion would ensue. That was literally the person's only contribution. (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.

commandlinefan 4y ago

I remember reading the agile manifesto around '99 or so (back then it was called XP, "extreme progrmming") and then, after having worked in software for going on 10 years, it was a breath of fresh air. I couldn't believe that logical, rational, sane principles of software development were not just being proposed by influential voices but were actually being considered by managers. 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).

deleted 4y ago
[deleted]
0xbadcafebee 4y ago
I mean, Agile just can't work at all, because it conceives of only one part of a business without considering all the other parts. I would prefer we popularized Deming's 14 points. That at least is achievable, and considers the whole business.