Focusing on the ‘team’ as the primary estimator is a mistake in modern agile style software management.
The typical claim is that “We will estimate these stories and build up a log of velocity data for the team.”, or “Story points are a measure of effort, but only for this particular team”. The problem is that there is no ‘team’. A software engineering team is not a stable long lasting construct. The average engineer stays at a company for less than two years. Your team is going to change month over month. Losing a senior engineer and gaining a new hire is going to effect your ‘velocity’.
In addition to constantly changing personnel, the work the team does constantly changes. In software you don’t build the same thing over and over. You do greenfield development, launch, add new features, maintain existing software, rearchitect software, wrangle legacy software and finally deprecate the project. In a software project that lasts 10 years the team spends maybe a year or two in each phase. And the team is doing totally different types of work in each phase.
So the first problem with focusing on the ‘team’ is that teams don’t really last longer at the company than engineers do. Teams evolve, their personnel constantly change, their work changes and their goals change.
The second problem with focusing on the ‘team’ is averaging engineers estimates together.
Averaging estimates robs engineers of the ability to calibrate their estimates.
The typical software estimate ends up as a single number in a JIRA ticket with no providence. We don’t know exactly where it came from. We know Jim the project manager added that number to the ticket, but at the same time Jim doesn’t actually make estimates. The estimate came from a ‘planning poker’ meeting where estimates from the entire team were combined into one big number.
The problem is that to make good estimates you need to be calibrated. You have to make estimates for various tasks and then come back later to compare your accuracy. Do you typically estimate low or high? Are you estimating much larger ranges of time than you should be? But if you don’t write down your individual estimates anywhere, you’ll never be able to evaluate your estimates.
Combining estimates from multiple sources is a key part of coming up with accurate estimates at an organization level. But if the only data you save is an aggregate estimate of the ‘team’, individual engineers can’t calibrate their estimates.
Consider tracking estimates at the individual level as opposed to the ‘team’ level. Individual engineers have a more stable identity than software teams. You can actually compare engineer Steve at year five in his career with Steve at year nine in his career. Over the same period a software engineering team wouldn’t be recognizable. And Steve can actually review his estimates and calibrate his output vs his predictions.