According to the Scrum Alliance:
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and product completion dates.
Now, setting aside that this definition seems to confuse calculated rate of work with forecast amount of work given that rate, doesn’t this sound like a simplified version of Earned Value?
- Amount of work planned
- sounds a lot like PV. But in less fungible units.
- Rate of work
- nods in the same direction as SPI/CPI at the planning stage. Continuing to measure it through delivery will give you a true SPI/CPI and allow you to forecast Variances at Completion. Assuming a fixed team size, this will map quite neatly to the trend on a Burndown Chart.
If you’re viewing Agile methods as a lightweight framework for small teams & simple projects; all well and good. But if you’re viewing Agile as an always applicable panacea, compared with the ‘bad old days’ of ‘Waterfall’ (in the perjorative sense, meaning a comprehensive methodology), then aren’t you just re-inventing the wheel out of spite?Recommend this post
Latest posts by Martin Burns (see all)
- Colocated Teams, Distributed Organisations - January 20, 2018
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017