We have finally decided to ditch time estimates and try something different, more predictable. Say hello to Team Velocity (for core agile knowledge please refer to SCRUM, agile framework used within our organisation). The idea behind it is trivial and understanding could dramatically improve delivered quality and make every customer happy. A few years ago JIRA started to play a huge role in our organisation. This neat development tracker & project management tool became our weapon of choice. Right away, a very natural approach to time tracking took the control over. After a long period of constant improvements, the only visible glitch was caused by an ideal hour. It was recently when we realised that this span could and never will be ideal.
Story Points (Commitment vs Completion)
On the nearest occasion, we decided to rethink our approach and swap to the more predictable solution. We chose Team Velocity. The name itself suggests focussing on the velocity itself. To make that measure relevant we started stating user story size & complexity rather than wrongly guessing their ideal development time. Every story then was broken down into development sub-tasks, where no estimation was needed. Suddenly, instead of chasing impossible to reach due dates, we found ourselves chasing tasks within sprint resolution. Team Velocity was automatically calculated when story points were burned, based on the established complexity scale. A good practice here would be to break down stories that have point count >= 100 so they always fit into one unit of development time (i.e. man-day).
Planning Poker & Team Velocity
Complexity Scale
- Near Zero (1)
- Micro (3)
- Tiny (5)
- Small (8)
- Medium (13)
- Large (20)
- X-Large (40)
- Split (>= 100)
Results after a few sprints were out of this world! While playing Planning Poker game, the whole team started to predict deliverables quite precisely. Developers, instead of constantly checking how much work was already done and how much time was left, simply focused on task resolution and burndown chart guidelines. As a byproduct of this new concept, Team Velocity was established, a measure already incorporating all the non-development interference of project’s life cycle. The outcome was more than positive. No more time wasting on inaccurate estimates. It’s a win-win situation, that brought back the balance between team’s management and development sides.
Burndown Chart
Development time is relative and impossible to predict. Every team is different, however, always Team Velocity is present, therefore why estimates should be based on something else? We honestly do recommend swapping to story points and estimation based on Team Velocity rather than always wrong ideal due dates, that could never be met. Currently, we believe it is the best approach. Especially if the agile methodology is something that your team is using while developing new products and solutions.
