Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use velocity to answer a very simple question and believe anything beyond this is wishful thinking. Is the team getting better over time estimating the effort to complete desired work?

The author here is charting velocity over time (down to the indivual developer, which is even worse) as some sort of work output proxy measure. This is a really big mistake. The entire premise for estimating stories in the first place is because we agree time is limited, so scope must be the variable. So you estimate stories, then you fit them into a fixed time period, then you execute and review the period. Did you get done what you planned? Probably not, why? I'll bet something turned out to be more work than you originally thought, or maybe you were blocked by someone else, maybe not even in the same team or even department. How did this period compare to previous periods? Is the planned/actual getting better or worse? Why?

As a manager I hope for steady velocity; it means the team is getting good at predicting the effort for work, probably understands what they're doing and allows you to make some plans for the future. People don't change the way the author's week-to-week velocity chart does, so all that shows is that they're still shitty at estimating stories.

One take-away that should be called out explicitly: velocity is a team-specific metric. Just as you can't divide it onto individuals, you can't compare it across teams either. Whenever you do either of these you're guilty of trying to inappropriately use it as a false proxy for performance. Please don't.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: