Velocity is one of the most common metrics used – and one of the most commonly misused – on Scrum and Agile projects. Velocity is simply a measurement of speed in a given direction, the rate at which a team is delivering toward a product release. As with a vehicle en route to a particular destination, increasing the speed may appear to ensure a timely arrival.
Even if Agile was initially considered as an anarchic approach due to practices like self-organization, the reality is that it requires a lot of discipline. Metrics is an important tool to assess the continuous improvement efforts of Scrum teams. However, setting a good metric program is not obvious. The book “The Agile Culture” contains interesting thoughts about what could make a metrics program fail.
In regulated industries like Health Care you have to comply with standard operating procedures, heaps of paper work and frequent audits. Do these requirements conflict with the core tenets of Agile? How do you increase velocity in such regulated environments?
In Scrum, the velocity is defined as amount of work that the team can handle in one sprint. This is an important measure as it is used to plan the future iterations and to verify that the team is progressing at a constant and comfortable pace. In this blog post, Agile coach Rachel Davies presents a FAQ on how to calculate velocity.
User stories and their size are often the basis for planning a Sprint in Scrum. You can use a relative estimation and planning poker or a more classical approach to define the effort for each user stories. As such, they are also the basis for the metrics of progress and the velocity of the Scrum team.
Velocity can be defined as a measurement of how much the Scrum team can get done in a Sprint, based on past results. In this article, Beth Macy discusses how reliable is velocity and how you can use it.
We would like solutions delivered fast without compromising quality, user experience, implicit requirements and non-functional aspects such as scalability and performance. This would have been easier, if we had all the time in the universe. Doing this in a sustainable manner becomes a huge challenge for teams as there are multiple competing forces at play and because software development is very complex.
Scrum Expert Copyright © 2009-2024 Martinig & Associates