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.

Author: 

Share this:

About the author | Ken Pugh

Ken Pugh is 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. He also trains, mentors, and testifies on technology topics ranging from object-oriented design to Linux/Unix. He has written several programming books, including the 2006 Jolt Award winner, Prefactoring. His latest books are Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration. and Essential Skills For The Agile Developer. He has helped clients from London to Boston to Sydney to Beijing to Hyderabad. When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail.


Comments

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

Managers want predicability 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 excersize. 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 deparment has multiple software projects (so you lose the concept of relative sizing) as well as ticket-response duties.

Share This Blog

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Design Patterns and Object-Oriented Analysis & Design, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
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, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Transitioning to Agile, Design Patterns and Object-Oriented Analysis & Design, Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Online Training, Professional Development, Agile