3 ms·
ok that was a really long and involved article, I will admit I didn't read the whole thing. If the punchline is the inverse of the title, then jokes on me. afa
by maerF0x0 4y ago
ok that was a really long and involved article, I will admit I didn't read the whole thing. If the punchline is the inverse of the title, then jokes on me.
afaik most agile systems are pretty clear that cross team velocity is non-comparable. (if if teams are shuffled the velocity will change).
But, the one thing it's meant to be used for is estimates. After sufficient iterations of the loop a team should both have increasing velocity (due to knowledge of codebase), and increasing accuracy of estimates (both dialing into sprint point / effort tuning, and knowledge of codebase) .
afaik velocity was never meant to tell you about how to improve itself. Thats more for Retros. (retrospectives)
- aprdm 4y agoThat’s only true if the team is working in the same sort of problems
- mandeepj 4y ago> After sufficient iterations of the loop a team should both have increasing velocity The velocity cannot keep on increasing forever :-)
- twic 4y agoIt can if the estimates do!
- maerF0x0 4y agook, obviously not forever... surprised you didnt mention eventual death of the contributors, heat death of the universe et al. Jokes aside, yes there is some asymptote of peak velocity that will reach. But keep in mind that some amount of effort can actually increase velocity in a net profitable way given long enough time windows... cue the table of automation from xkcd[1]. Imagine if we're playing with legos, and instead of using the smallest units I start to build with bigger blocks? I can build the same house by placing fewer blocks (analogy-- faster) . [1]: https://xkcd.com/1205/ https://xkcd.com/1205/