Agile team members work together to groom, plan, commit, and deliver work every sprint. The number of story points that a team delivers in a sprint is known as velocity.    Velocity Definition Velocity is thus a measure of the speed (ideally, expressed in story points) at which an agile team delivers work every sprint.  Who invented velocity in Agile? Velocity was invented or created to help the teams feel empowered and self organized.  Ron Jeffries, one of the 3 founders of XP (extreme programming) explains that the concept of estimating using “ideal days” got confusing to people. An “ideal day” is defined as a day of work without any disruption.  Acknowledging disruption, they would multiply “ideal days” estimate by a “load factor” to translate the (ideal) effort to real (time) effort. So, an effort of 1 “ideal” day” with a “load factor” of 3, would mean 3 ”regular“ or ”real“ days of effort.  However, while continuing to estimate using “ideal” days, the word “ideal” was ignored (not spelt out) but assumed in the team discussions and stakeholders failed to catch that. You can imagine how it could have created confusion when a team was estimating 1 “ideal day” (but actually meaning 3 real days) of effort, and stakeholders assuming it to be 1 day of effort but not finding work complete on time and complaining about it! This is where Ron and team started using points instead of days referring to 3 “ideal days” as 3 points and meaning 9 days of effort and so on… Thus a team finishing a certain amount of points in a timeboxed period came to be known as velocity (speed)   Wise use of velocity Velocity is an important metric, if used wisely and understood properly. Unwise use or abuse of velocity creates issues and leads to teams and leaders wanting to avoid using it. Velocity numbers may increase organically as a team becomes stable in its composition and consistently grooms, estimates, and swarms together. Such an increase in velocity should be a welcome thing. When teams are pushed for increasing their velocity or velocities are compared between teams, it can create wrong habits and anti-patterns. This is where teams sometimes start what is known as “story point bloating” (Giving more points to stories to show an increase in velocity). This is one of the sad things to happen and contributes to fake Agile and people wanting to avoid Agile and Scrum For teams that swarm together and work to finish their team commitment as a unit (“All committed work is ‘our’ work and not mine vs. yours”), their process efficiency increases and may lead to an organic increase in velocity. Such an increase in velocity is a win-win as it shows the value of Agile done wisely and brings value to teams, users and customers. You will notice that for most teams the average process efficiency is quite low (less than 5-10% or lower) Even a 10% increase in process efficiency can have a good impact on velocity. Stable velocity and high predictability are important ingredients of an Agile release plan   How velocity is misused and abused? A good team works to establish a stable velocity range along with high predictability. These are important ingredients for a team to plan their releases. The knowledge of previous (Sprint) velocities, along with clarity on (next Sprint) availability (team capacity) of team members helps the team plan better in the upcoming Sprint.  A number of factors can prevent a team from establishing a true and organic stable velocity range. Some of these factors are: Prevalent culture that disrupts the team’s committed work Prevalent culture that disrupts the team composition repeatedly Team members not estimating consistently as a team Lack of deeper understanding of Agile and Scrum values and principles Attitude of “we know it all” but failing to show it through actions   When leaders do not understand deeper agile values and principles, lack servant leadership,  tend to track or compare velocities of teams, they create environments where teams feel unsafe, carry mistrust and fear.  This results in creating negative and unhealthy pressure which results in abuse of velocity. Teams feeling under pressure tend to manipulate the story points, to show higher velocity. This is indeed a sad thing to happen and is highly detrimental to the foundation of Agile Leadership and management must be educated and coached to never compare velocity charts or numbers of teams in order to avoid slipping into the above habits and anti patterns   Velocity and Predictability  Predictability is defined as the number of points completed from the committed ones. Like Velocity, Predictability can also be abused. Remember, good teams use metrics to validate how effective they are instead of putting(fixing) data together to show great metrics! Total committed points are usually committed towards the end of the Sprint planning meeting. A team that works effectively, is empowered and supported by their leaders and grooms, plans and commits as a unit is likely to complete most of its commitments.  When teams are not yet effective, it is common to see scope changing throughout a Sprint and even if the team may have finished “number” of points equal to what it committed during Sprint planning, they may not be the same stories (or story points) as planned due to the change of scope after Sprint started.  When such behavior repeats, it becomes a habit, and an anti-pattern. Eventually, the true meaning of predictability is lost and planning falls apart.  A good coach will work with the Scrum Master and developers to help them understand organic ways to account for unplanned work and may suggest using Kanban (instead of Scrum) if there is too much disruption to planned work repeatedly. Teams that have swinging  velocity will most probably struggle to have a high predictability consistently due to lack of ownership and accountability resulting in little collaboration and swarming   Velocity myths and facts 1. Is velocity the only way