:) actually thats a good way to describe it to non software executives you don't want asking too many questions, lol I used it as the generic estimation of work (1 should be the lowest) ...and then the team's velocity per sprint/PI would let the PO/PM give us an estimate of time... Let's say Larry in this case is on Scrum Team "Banshee's Ballers" w/8 individuals.. and they have a velocity of 60 points per sprint.. and lets say a sprint is 2-4 weeks (we'll say 3) given the organization (Bungie may employ certain strike/tiger teams with a week or less even).. and so 60pts in 15 work days (no vacay/other discrepencies).. could be 4 pts a day for Banshee's Ballers.. and so I'm saying Larry could do this in no time... I would even say.. I know this is scary given Bungie history.. but simply removing a perk from a possible pool of future drops (not even requesting it be changed in older drops.. which I want but let go cause its Larry).. will require no testing. Just straight up delete the text/function whatever that calls full auto perk.

When Ron Jefferies invented story points (he doesn't claim 100% credit, only that he was in the room), it was to "obfuscate duration," because people are terrible at estimating time, as well as for the reason you mentioned, to get execs to think in terms of relative effort (relative to a team's smallest, 1-pt. baseline, story) rather than time. He has since apologized for supposedly inventing story points, saying, "I have never seen them work well and, only occasionally, work well enough." But that said, yes, if you have an established velocity and a prioritized backlog of consistently (consistency > "accuracy"... i.e., a clock that's always exactly 3 hours fast is more useful than one that's "more accurate" but sometimes a few minutes fast, sometimes a few minutes slow) estimated stories, deriving when they're likely to finish is easy math assuming priority and scope don't change. Average cycle time per story point is too advanced for most SMs to usefully leverage, but it can be interesting and help prove why capacity should be based on empirical velocity, not a cookie cutter formula (x number people on a team * some constant - days off) and why you can't compare teams' story point velocities or, for that matter, add teams' story point velocities (i.e., to calculate a train's PI velocity, something SAFe, most companies, and most alleged Agilists get really, really wrong... one day SAFe will learn to calculate trains' velocities in feature points -- or even better, value delivery -- rather than story points, where feature sizing is much more consistent across all teams.) How the hell did I end up down this rabbit hole? LOL.

yeah I think the key for me there that I've seen is "established velocity" as in experienced team members (experienced working with each other and the rest of the RT).. that will make the estimate more comfortable because its still business that has deadlines... and thats why Agile was created in the first place to punch out useful quanta of software (or for us as players the dreaded Bungie MVP) ...but def understand the need to "obfuscate duration" to execs or non-software folks (sales, hardware..etc) ...should work if you adapt the method to the people.. as long as the people understand/accept the reality of business needs... and I like keeping good feedback loops / communication channels to help LOL > goooo Banshee's Ballers... can only hope Larry sees this forum post in year 2024

Best team name I ever saw was a team of coaches I was on about 6 years ago, "Burn Down for What"