Introduction

My team is working using an agile methodology and several weeks ago we were planning the next sprint. I was in a meeting with my PO (Product Owner) to check the last details when I had a very interesting conversation. We were dividing the work for an epic in tasks and estimating the time to complete them. My initial idea was to create the tasks so that they took less than five story points to complete. I think that I got that correctly as the biggest task was estimated to be three story points. That’s when my PO came into play and advised me to further subdivide the work. I should create subtasks for the tasks, and estimate them in hours, rather than story points. Moreover, I should plan the subtasks to take less than a day. He wanted the team to increase accuracy and split tasks to see progress while the feature is still in development.

Velocity and Accuracy

I hesitated because that meant more work in the short term, and the long-term benefit was not clear to me. I would have to invest more time on this task in the coming days to further investigate how to implement each of these tasks. So, my PO and I had a long talk about why it was better to have a better idea of what needs to be done, thus increasing the estimation accuracy.

This brings to the two terms that I wanted to discuss in this post:

Velocity

The Oxford dictionary defines it as “the speed of something in a particular direction”. Increasing velocity means that a given work takes less time to complete.

Accuracy

The Oxford dictionary defines it as “the state of being exact or correct”. Increasing the estimation accuracy of a given work means that you can plan those tasks in advance with more certainty that they will be completed on time.

Velocity vs Accuracy

In my opinion, in an agile environment those two terms are in conflict. As increasing one of them means that the other will be decreased. As an example, to increase the estimation accuracy I had to decrease my velocity. Why? Because I had to investigate more deeply how to implement the epic I postponed doing other work, thus lowering my velocity. In addition, some of this research would not provide any other long-term benefit, as the actual implementation would occur several weeks later and by then I would have forgotten the learnings from the initial research, thus having to re-investigate them again.

On the other hand, making a perfect estimation planning would allow me, and my team, to know in advance how much work I would be able to deliver in a sprint. But that’s difficult to achieve (if not impossible), and it means that once I commit to a given amount of time I risk not delivering it on time. This would not be excessively tragic if the deviation in the estimate is low, but it could also be that the deviation is high and this could have big consequences.

Conclusion

I like experimenting so I decided to follow my POs advise for this epic. Thus I investigated deeply how to implement the epic, divided the tasks in subtasks and estimated them. My plan is to analyse the results of this way of planning when the work is completed.