• Português
  • 简体中文
  • 繁體中文
  • Deutsch
  • English
  • Español
  • Français
  • 日本語
  • Latviešu
  • Lietuvių
  • Русский

Submitted Conference Content

Full name

Ankita Kanitkar

Job Software Developer
email ankitakanitkar [at] gmail [dot] com
Company Tata Consultancy Services Limited
City (Country) Mumbai
Time 30'
Type of Conference Conference > 100 attendees
Level Everybody

Are our Teams more focused on Velocity?


Ankita Kanitkar is working with Tata Consultancy Services Limited as a Software Developer for around Five years now. She has been practicing Scrum since last 3 years. Ankita is primarily working on technologies like Java/J2EE and Ruby on Rails. Apart from development she also facilitates Scrum Introductory session for the new collegues joining the team.Ankita is a Post Graduate in Computer Application from Maulana Azad National Institute of Technology, Bhopal.She has also been a part of a team organizing conferences and workshops at the client relationship level. She enjoys singing and event organizing a lot.


A user story represents business value to the customer and velocity is the rate at which a team delivers value. One burning question that hovers in a sprint review or any weekly update is around the Team Velocity or trends that the team is demonstrating. Though velocity helps to figure out the rate at which a team is performing but considering it as the only litmus test ! may actually impact the project productivity in long run. Teams in order to catch-up with the benchmark velocity may get diverted from the quality or testing effort that a story may require and yet mark it as done. Velocity is a vital component of iterative planning, but it has been observed that at times, the teams tend to rely too much upon velocity as the only measure of their success. Hence instead of considering it as a 'measure of capability' to deliver the teams add certain misconceptions to its definition. In this discussion, I want to highlight some of such Do's and Dont's and overcome the Dont's in order to become a successful team. Agile teams, focus on delivering features of highest value but this motive is hampered when the team is stressed with too many questions on productivity. Some 'managers' fail to appreciate and interpret the definition of velocity and turn it into a productivity barometer. Nonetheless it is important indicator, but even more important is measuring feature value, feature delivery cycle time, and quality measures. As a developer I want take the audience through various scenarios where velocity is considered as a measure of teams especially developers productivity. And want to caution that such scenarios give way to unhealthy practices like making adjustments to the estimates, to give a beautiful picture about the teams performance that may be far from reality and result in buggy product.

Benefits for the attendees

The talk would help the audience to understand the importance of velocity as a measure of capacity rather than productivity.It will also detail the repurcussions that can be faced when velocity is over emphasized - the first and foremost being the stress to the team and compromises on the product quality.

Go to the submission page!