A rather lively debate has been taking place within IndigoBlue regarding the validity of reporting optimistic velocity (i.e. not 100% complete and tested). I thought it might be interesting to share...
Focusing the team on completion is a fundamental requirement but it is often hard. However, introducing any form of "interim" completeness is counter-productive. The difficulty is that if you apply rigorous criteria to accruing velocity there is a likelihood that the velocity counted is low compared with the actual amount of work done. As an extreme example if there are no testing resources available during a sprint, at the end of that sprint the velocity is zero. Even in less extreme cases there is always going to be some work in-progress at the end of a sprint.
This low velocity has to be fed back to three sets of people:
Resolving the problem of too much incomplete work requires two lines of attack: fixing the behaviour; or reporting something more realistic. The second part can drive PMs to start "making up" up a velocity, or subconsciously relaxing the completion criteria, on the basis that reporting the real velocity is "unacceptable" (or at least mis-communicative). Our thinking was that it is better to report a velocity BAND which retains "factual" information (i.e. partially complete) and maintains the rigorous velocity measure, rather than allow the definition of completion to be diluted.
By reporting a band you can also perform governance on whether the width of the band is increasing. This can be seen as a governance-level metric for how successfully batches are being closed. A win-win situation?
Today's highly competitive and rapidly changing markets that see the rise and fall of the likes of Nokia and MySpace places business imperatives on companies. In particular, companies need to be innovative, introducing new products, updating others to react to changes in the market (or predicting or even creating these market changes).
Comments
Post new comment