Velocity is one of the simplest but powerful tool to predict the future completion date of the project.
Velocity is the capability of a particular team to deliver certain set of requirements within a specified duration.
It is very important to note that, this is true for a particular team with a fixed duration. If the team and duration changes then the velocity changes automatically.
Based on my past experience interacting with several teams, I found that following misconceptions misguide the teams. As an Agile coach or Scrum Master, it is very important to help the team to understand the true meaning of Velocity and drive away the myths and misconceptions.
Myths and Misconceptions
Wrong | Right |
Velocity is productivity | Remember, Velocity is not productivity. Productivity is how busy your team is. When some one is measuring productivity, they don’t measure the value generated out of it. Productivity is also measured against a standard. However, Velocity is for a particular team, particular context and in a specified duration. Velocity could be tied to business value. |
Velocity Standardization | Many leaders think of standardizing velocity across multiple projects and sometimes throughout the organization. This is totally wrong. As said before, each team is different, trying to enforce velocity of one team on another results in increased stress, loss of morale, productivity and finally loss of value to the customer. |
Converting Velocity measured in Story Points to an absolute number in Person days | I have seen many Scrum Masters trying to convert the Velocity measured in Story Points to Person days. For example, 80 Story Points = 60 Person days. Again, this is wrong. The above conversion basically freezes the delivery capability of the team upfront. If the team is new to a technology or a business domain, the capability to deliver would be less. By freezing the story points upfront, the new team would struggle a lot and will get stressed out. |
Comparing Velocity among teams | Since Velocity is specific to a team and within a context, it does not make sense to compare the velocities between teams. A team comprising of Oracle Experts working on Oracle technology obviously will fare well as compared to a team of fresh out of college put on a similar Oracle project. Velocity of both the teams would be different. Never compare velocity between teams |
2 comments:
Great post!
> Velocity could be tied to business value.
I can not understand here.
I think velocity is a total storypoints of stories which were done in the sprint and storypoints does not represent business value. (only size of the feature)
If you can , please tell me more details.
I believe, Velocity has true meaning and carries weight only when the burned story points is adding business value to the customer. So, one should tie Velocity to the business value delivered.
Post a Comment