 | |
| Should Management Use Velocity as a Metric? |
Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working. That’s not what it is at all. Velocity is a measure of the rate at which the team is delivering stories. If the team worked long and hard on 5 stories but delivered none, then their velocity is zero.
Because of this misunderstanding, I find managers who think that it is important for the team to work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Faced with a manager who wants to track velocity as a management metric, a scrum master needs to identify what the manager is trying to measure, and what business decisions they expect to make with that data.
Downoad Also:
The scrum master can then help the manager find more effective ways to get the data they need to make their business decisions. If the manager wants visibility into how healthy the team is, or perhaps how productive they are, we can provide them much better metrics. Trying to use velocity for these purposes won’t work.
Imagine that you are on a team, and your manager wants to see the team’s velocity increase over time. This is very easy to achieve, the team can simply increase their estimates for the user stories.
Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule.
Velocity is a great tool for predicting what the team can deliver in the future, so long as the story points aren’t being inflated. If a user story that the team estimates as five story points today is not approximately as much work as five-point stories estimated in the past, then predictability is lost. Everybody loses.
So what is a better management metric? Number of stories delivered. It’s imperfect, as all metrics are, but it is much better than velocity. Measuring the number of stories delivered per sprint will drive a number beneficial behaviors, and gives a manager a better window into the health and productivity of the team. When a story is done, the team has delivered value to the business. This is what the business wants. Think about it.
The business exists to create value, not to create busy people. When we measure the number of stories delivered, we are measuring the rate at which the team is delivering value. More stories delivered means more frequent delivery of value.
So what if we game the metric? Remember, that to game velocity the team inflates estimates. To game the number of stories delivered, the team will break their stories down into smaller stories. There are many benefits that come when the team works on smaller stories. Smaller stories are easier to understand and thus easier to implement correctly.
Smaller stories will get delivered more frequently, which allows more frequent feedback. The team will get more frequent product feedback from stakeholders, so they can make more timely adjustments to the product. More frequent story completion means the team will update their burn down chart more often, and have much better knowledge and control of their schedule. Smaller stories also mean the variance in the team’s velocity, the natural up-and-down swings, will be smaller.
Additionally, the more frequently the team delivers functionality to users, the more frequently they can inspect and adapt their architecture, design and technology choices. I’ve previously written about How to break big user stories into smaller user stories Might the team go overboard with this? I’ve never seen it. I’ve worked with hundreds of teams and I’ve never once encountered a team who’s on-going problem was that their stories were too small. On the other hand, most of the teams I coach are having problems because their stories are too large.
Related Topics:
So measuring number of stories delivered leads to smaller stories, which increases the rate at which the team is delivering value and also speeds up the various feedback loops that keep the team building the right things.
The Author: Ala'a Elbeheri
About:
A versatile and highly accomplished senior certified IT risk management Advisor and Senior IT Lead Auditor with over 20 years of progressive experience in all domains of ICT.
• Program and portfolio management, complex project management, and service delivery, and client relationship management.
• Capable of providing invaluable information while making key strategic decisions and spearheading customer-centric projects in IT/ICT in diverse sectors.
• Displays strong business and commercial acumen and delivers cost-effective solutions contributing to financial and operational business growth in international working environments.
• Fluent in oral and written English, German, and Arabic with an Professional knowledge of French.
• Energetic and dynamic relishes challenges and demonstrates in-depth analytical and strategic ability to facilitate operational and procedural planning.
• Fully conversant with industry standards, with a consistent track record in delivering cost-effective strategic solutions.
• Strong people skills, with proven ability to build successful, cohesive teams and interact well with individuals across all levels of the business. Committed to promoting the ongoing development of IT skills throughout an organization
Post a Comment