Need for speed on Agile Dev Team
When building software, moreover for large size projects, we always need for speed. On Agile Scrum, speed is measured by velocity as the average story points that can be completed during a Sprint iteration.
Of course velocity, it’s a relative measure since each team (depending on size of team) has it’s own steady velocity based on many facts (such as sprint duration, code ownership, tech skills ) but it give us an idea of how fast the team could ingest the backlog for releasing a version.
The question that arises is: How to discover our Team Velocity?
The purpouse of this artitle is to share with us, a couple of stratergies that help me to discover the Dev Team Velocity:
- Chill High Expectations
- Increasing Team self-confidence
For both cases, we will need to run at least 4/5 iterations in order to unveiled an stable velocity. If the project is too short that this can be done, don’t care about Velocity.
Chill High Expectations
First stratergy, is start trying to asume the Team could complete more issues than his own feeling on planning (initial 50% more) which is exactly to high Expectations. In many cases, what happends is that result completed story points are less than commited.
On the next iteration, lowering high Expectations will make commitment be more near to completed.
When Commited story points are almost same as completed story points, on at least 3 or more iterations, we could says this could be the target Velocity of the Teams, and future Sprint plannings should be as large as Velocity in order to be able to completed commited.
Increasing Team self-confidence
The second stragery, is to commit at least the feeling of the team. First iteration could be exploratoy in order to set initial value(lets say 60% of the team belives can complete).
On the next iteration, planning never overpass 15% story points than completed on the last iterations. The idea is start commitment lower and start increasing as team confidences increases too on each iterations.
When the completed story points reaches an stable value, we have reached the Velocity
Conclusions
Knowing Dev Team Velocity is a good idea because it gives the team predictabiliy about how much story points can be commited.
How Fast? As fas as possible? It depends. It’s no a good idea to go faster if we compromise testing, code reusability and a sustainable rythm (as Thomas Wallet mention on this article)
It’s also a suggestion to use a Software tool like Jira in order to work with Scrum in order to automatically compute Velocity for every iteration rather than doing this manually.
