Don’t Compare Apples and Oranges – Inter-Team Velocity Comparisons

October 10, 2011 — Posted by Ken Pugh

Velocity is the number of story-points completed during an iteration. It is the most common and natural metric for teams using iterations. Time-over-time, the team can measure its increase (or decrease) in its effectiveness in delivering releasable implementations of requirements. It is powerful and effective within a team.

It is not, however, effective between teams.

Velocity depends on story-points and story-points are relative estimates to other stories that a particular team is working on. They are not relative to what other teams are working on. One team may use an approach that assigns 5 points and 3 points to two stories that a proportional effort of about 150%. Another team may assign 3 points and 2 points. The first team will show a higher velocity, even though the work effort is the same. If the two teams are being compared based on velocity, then the second team could easily push up its velocity merely by 8 and 5 to the two stories. Same work but arbitrarily different velocities.

Some organizations try to standardize story-points. This seems reasonable, but it does not work. For example, they might provide standard stories that are given story-point values. One problem is, these standard stories do not take into account the wide variation in the actual stories that are worked on by the teams, the communication and relationships between the requirement detail providers and the implementers, and the details that emerge when the stories are implemented.

The other problem is that teams are not homogeneous. They have different numbers of people with different skill sets and experience in the project domain and the technology. They may also have different responsibilities for work outside of the main project which they are implementing.

Velocity is for a team, not for inter-teams.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.


Comments

What are the underlying problems that lead to people wanting to have inter-team velocity?

Managers want predictability on projects with minimal up-front investment; as I call it, Agile-level pre-work with Waterfall-level estimation accuracy. They want to be able to predict how long two apples and oranges tasks are going to take by just simply doing a pointing exercise. It never works out as expected, and if it does, it's a happy accident.

The worst thing I've seen is our attempts at "Department-Level Kanbans". The velocity these establish is basically a meaningless number. Because a single department has multiple software projects (so you lose the concept of relative sizing) as well as ticket-response duties.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban