|   Agile, Blog   |   No comment

I was recently emailed asking how a group of teams might better measure their velocity. The exchange might be interesting to more folks, and I’ve posted it here in the case that it is useful:


Awesome to have the conversation go a bit deeper. The definition of velocity Scrum Inc uses is: the amount of work done sustainably and with quality. We always ask for 4 measures when we coach teams: Velocity, Quality (defects found in field, support calls, cyclomatic complexity, or the best the team is measuring now), value (NPV per point), and team happiness (Happiness metric).

We then are brave enough to get specific about quality: The amount of work accepted by the PO as “done” during the demo that meets the current definition of done at a pace the team votes they can continue indefinately ( principle 8). The definition of done must include tested, and we encourage the team to elaborate that with “elegant design”, “refactored in place”, test driven, automated tests, gated check-in, unit testing, integration testing, regression testing, exploratory testing, compliant with OOA (and therefor loosely coupled), etc. In this way while it should become more difficult for teams to complete a given amount of work within a sprint, we find as they evolve the habits to produce elegant and excellent solutions they actually continue to speed up.


Measuring historic or baseline velocity, to compare previous speed with speed after a Scrum transformation:


1) They measured in velocity points ( To measure previous velocity, they used a two methods: A) use the first 3 sprints velocity average as baseline. B) estimating the backlog of the most recent delivered project and taking the point values, then dividing by the time it actually took to ship.


No Comments

Post A Comment