The worst thing any team can do is to raise expectations through early success, but be unable to sustain the pace. This happens to many Agile teams due to some simple mistakes made in tracking Team Velocity. As a result of these painful misses, some organizations are getting a bad taste for Agile, and are once again looking to the next big idea to get the performance they want.
Let’s look at the formula for velocity: Velocity = Story Points Accepted/1 sprint
Pitfall #1: Story Points Accepted.
The way a team determines whether a User Story is accepted is important. If a team does not have a strong Definition of Done it is likely to inadvertently count stories as Accepted (and therefore part of velocity) when in fact they may still need work such as complying with code standards, including logging & exception handling, fixing defects or even handling minor requirements that fell off the table during the sprint.
Over time, this debt builds up and dealing with it will cause an unexplained loss of velocity.
The Definition of Done is owned by the team, and varies between teams. An example of a strong Definition of Done is:
- Code is written & unit tested
- Code has passed technical walk-through/review
- Product Owner has received an informal demo
- Test plan has been fully executed and all defects have been fixed
- Technical documentation (if any) has been written
- Code has been integrated with continuous build scripts, along with all DML, DDL, web service registration and other environment configuration elements.
If a team does not maintain and adhere to a strong Definition of Done then Team Velocity really doesn’t measure work that is truly finished, and is not useful as a gauge of success.