3 ms·
I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.
by jf22 2y ago
I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.
- n4r9 2y agoNot the person you're replying to, but I'm not convinced there's a difference. Discussions about velocity boil down to "how much can we fit into the next sprint/month/quarter". This typically feeds into some kind of burndown or roadmap update. However it retains the pitfalls of estimating something that is often unknowable in advance. I may be misunderstanding your comment in which case I'd greatly appreciate clarification as I really struggle with workflow planning.
- jf22 2y agoI'm convinced people understand the difference. Everyone struggles with workflow planning and that's why people use the old mid 2010s scrum terms differently now.
- n4r9 2y agoI've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for? In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".