Imagine you have a team, working hard, delivering good stuff. Then the sprint ends and …. velocity has dropped. Oh no what happened? Someone get married in Bermuda and invite the whole team? Outbreak of Plague? No something much more insidious, the work that was done, wasn’t work, at least wasn’t included in the original definition of work which is the same definition the remaining Scope is defined by.
Basically the team delivered a few new stories – realisable value – attributable against total remaining scope; then they resolved some tech debt, closed a few bugs and performed a tech spike on something for a subsequent sprint. If those work “types” are not treated like stories with estimates that are included in the total remaining work scope figure then you’ll see a drop in velocity.
If you are working on a Product evolution – the classic Agile case study of an e-commerce site, then this might not be a problem, especially if the team can keep the non “story” work at a consistent level so the velocity doesn’t drop, (it always bumps along at the “dropped” level). However if you consider a scaled release based system with tight timelines and a need for strong scope control, then the picture changes. The release based model will have (however unfortunate) a natural tendency to have an uneven delivery of Work “types” throughout the release, more spikes upfront, more defects at the end etc – so velocity will be unpredictable.
What is velocity anyway – why do we care. Well in the complex scaled world, Velocity is the yardstick that the consumer of the sprint/release – all the way down to Organisational Change Management – use to manage expectations – whether something will fall in the release or not. Therefore the most useful characteristic of velocity for the business is consistency.
To move to consistent velocity – then at the very least all work needs to be included, and obviously you need to report velocity in the same units as the total Scope, which means that these new work “types” need to feed into the remaining scope of the programme.
I ensure that the tracking tool used can identify between these work “types”, so if someone wants to see remaining STORIES, or last release’s effort on defects, then they can. But the headline, CEO scrutinised, view of progress against target needs to include ALL WORK.