Stop Using Velocity to Manage Across Multiple Product & Project Teams

If you’ve managed a project or product development team, you’ve definitely used some type of sizing g technique (t-shirt sizes, Fibonacci numbers, etc.) to determine the amount of work that can both occur in a sprint as well to determine any efficiency gains that development team obtains over time.

However, while determining the velocity and using it to manage one team is fraught with error, using velocity in a Product or Project Management Office to manage a portfolio of projects breaks down completely for the following because of the differences amongst teams.

Differences amongst teams

Individual teams change over time. While a loss of a team member will normally reduce the amount of work which can be done (unless the team member was fired for lack of ability), the addition of a team member will naturally change the estimation of a pointing system because during the sprint planning meeting, this new individual’s input can change a ticket from being 2 points to 5 points. This change in estimation both creates the perception that the velocity for the team is increasing and makes any historical trend analysis invalid.

Since velocity encounters multiple issues with one team, using velocity as a PMO’s managing data point to forecast feature completion and compare efficiency gains across multiple project/product teams doesn’t work.

Therefore, if a PMO can’t rely on velocity to manage its portfolio of teams, it must use alternative data points to fulfill its management role. Below are the 4 data points on which a PMO can rely.

Quality Assurance and Rework Ratio

If you have a good QA process then your development team is catching non-workable and/or code that doesn’t meet the task requirements. A high performing team has a low number of tickets related to Q&A rework. As a team continues to mature and become more efficient, that team will reduce the number of tickets related to Q&A rework.

Software Development Cycle Time

Unlike velocity, which is highly variable between teams, Software Development Cycle Time measures the time between first commit to a production release. This is an important metric for a PMO to track because this metric can be used across teams and a low time is indicative of an optimized development process which brings features more quickly to market than a high time.

Iteration Churn

Unlike QA and the Rework Ratio, Iteration Churn (a better term is “Sprint Churn”) measures the number of changes to a sprint’s scope during the sprint. Now, while it is true that scope changes are not always the result of the development team, the development process doesn’t start and stop with the development team, it has many inputs all of which are supposed to be consolidated with the Product Owner who makes priority decisions for the product.

Bugs Found in Production

Unlike bugs and rework found in house, these bugs are found by customers. Regardless of if the bug is small or large, customers take notice and judge the quality of your product by the number of bugs that they have to report to you. While it is highly improbable that a customer will never find a bug in production, the quality of the work produced by individual project/product teams can be gauged by this ratio and compared to other project/product teams.