The Hidden Perils of Sprint Velocity: A Scrum Master's Tale

This post discusses Sprint velocity conflicts and the dangers of poor management. In my experience, I encountered a Scrum team extremely concerned about their velocity. The team consistently put forth their best effort every sprint, diligently working to complete their committed tasks.

Everything seemed great, and the team celebrated their achievements after each sprint. However, I noticed a hidden issue that made these achievements seem less impressive. Occasionally, the team was willing to take on extra work not included in the sprint scope, leaving the original scope untouched.

The danger here lies in the sprint scope not accurately reflecting the team's efforts. This directly impacts the accuracy of future sprint planning and delivery expectations. If third parties or even Product Owners (POs) become accustomed to the team performing beyond expectations, it could lead to unhealthy habits.

Another danger is that the sprint goals are not entirely realistic, making them less trustworthy to users and stakeholders. This situation risks damaging the trust between stakeholders (or other business-side parties) and the development team.
Upon delving deeper into the problem, the team expressed fear of facing unrealistic expectations, stemming from already established habits. They were hesitant to admit they could handle extra work, fearing it would suggest their velocity was underestimated.

Now, having shared all the details with you, the solution might seem obvious. We adjusted the sprint scope by removing some unstarted, lower-priority tasks to accommodate new requirements. If no such tasks could be removed, the new, unexpected requirements should be shifted to the next sprint with high-priority level.

On the other hand, this confusion stemmed from a poor understanding of agility and its values. Highly experienced developers would conceal their extra work, treating it as additional development. Identifying this issue was challenging, but once it became clear, the solution emerged naturally.

As a Scrum Master my approach involved conducting several Agile training sessions for developers, explaining the main values of the framework used and demonstrating how agility aids development. (I'll discuss more about this in my next post.)
Additionally, an open conversation was necessary with stakeholders, users, and PO. (More about this in my next post.) It's crucial for the business and development sides to work with the highest level of trust and transparency possible.

I'd love to hear if you've encountered a similar situation as a developer or Scrum Master and what you think is the best way to resolve it. Your insights would be invaluable to me and anyone who might face a similar situation.