Specialized Velocities

A department store’s business is partitioned by markets, with each department serving its own market. Each department has its own team that processes work for its market at a pace that it establishes, independent of the pace in other departments.

... your product has grown to multiple teams, and some teams have developed along lines of specialization. The Product Owner wants to maintain one velocity for the Product Backlog.

✥       ✥       ✥ 

It is difficult and wasteful for a team to estimate PBIs outside its line of specialization. For example, you probably don’t need a team working on the infotainment system for a car to also estimate the PBIs for (the specialized area of) the brake system, so involving them in such estimation would be wasteful. On the other hand, we want to recognize the ability of individuals to contribute from their perspective. In fact, key insights sometimes come from the most unlikely places. As human beings we all have insights into all human phenomena. However, that isn’t reason enough to drag all of humanity into an estimation exercise. A good approximation is enough. Estimation is waste in the value stream and we should minimize its cost.

Teams naturally tend to specialize over time, given the opportunity. There is no fundamental problem with specialized teams as long as there is no à priori partitioning of product development that precludes any team from working on some part of the system outside of their usual purview. For example, when there is coupling between the infotainment system and the brake system that may realize a security leak. A design shortcoming arises that allows the car to be commandeered by a hacker who first seizes control of the infotainment systems, and use the security flaw to take over the brake or accelerator. Either the infotainment or brake system teams should have the ability to work outside their area to focus on the issue from the market perspective, rather than the technology perspective. Teams estimate with the knowledge that they will freely work with each other during implementation. And though specialization can bring focus, it cannot be an excuse for any team or individual to refuse a PBI for inclusion in a Sprint.

The Aggregate Velocity approach does not depend on specialization and handles the fully general case, albeit at a cost of creating a large meeting. Individual voices tend to get lost in these large meetings, or the meetings bog down because of their size, or time boxing and other expediencies cut off discussion prematurely. If there are more voices to be heard and if you believe there is value in hearing them, it will take more time to collect the key insights from a large group than from a small group. And though the time spent eliciting input goes up, the amount of unique insights goes at a disproportionately smaller rate.


Each specialized team estimates and develops items within its realm of specialization. These estimates are informed as necessary by input from other PBI stakeholders. For example, you can elicit these stakeholders’ input by first asking the specialized team to make an initial estimation pass and then subsequently refining the estimates in areas outside the team’s experience, inviting external stakeholders as necessary. Many alternative approaches work just as well.

✥       ✥       ✥ 

The team will feel committed to the estimates in the end, and will be able to size its Sprint Backlog appropriately and with confidence.

Teams should not specialize along the lines of engineering technique; that is, there should be no testing team or coding team or architecture team. This pattern addresses specialization along the gradient of the value stream. You might consider writing and socializing patterns as Market Team (which develops products for a given market) or Localization Team (which adapts a product to an ethnic market segment). See Value Areas and Value Stream Fork.

Specialization creates stovepipes that could suffer from starvation in a given Sprint. If team A specializes on the infotainment system and team B specializes on domain the brake system, and if the candidate Product Backlog for the current Sprint doesn’t contain enough items for team B, then either team A will end working on items outside its specialization or we will need to reduce the number of estimation points taken into the Sprint. Solve this by avoiding lines of specialization when you have only a few teams. You will move more towards Cross-Functional Teams, expanding each team’s ability to do competent work in a broad number of areas. [1]

This specialization was a contributor to the success of the oft-cited Borland QPW project [2], though it is important to note that QPW did not meet the team’s anticipated schedule.

See also Team per Task.

[1] Craig Larman and Bas Vodde. Scaling Lean & Agile Development, Addison-Wesley, 2009, pp, 176-187.

[2] James O. Coplien and Jon Erickson. “Examining the Software Development Process.” In Dr. Dobb’s Journal of Software Tools 19(11), pp. 88-95, October 1994.

Picture from: https://commons.wikimedia.org/wiki/File:Paris_Lafayette_inside.jpg (in public domain).