Velocity measures the amount of effort the team can commit to, on average, in any given sprint. There can be many reasons for this. It could be that the team has grown in their technical skills. It could be that the team works better together because they've reached the last part of the Forming, Storming, Norming, Performing stage. It could be that organizational impediments have been resolved, clearing the way for the team to become more efficient. It could also be that the team has removed team barriers to increased productivity through the frequent inspect and adapt process in the sprint retrospectives.
If velocity increases, then more value is theoretically being pushed live to users.
Regardless of the exact circumstances which led to the increase in velocity, it seems some form of growth has occurred. You could use velocity to showcase that a team has "grown", but it doesn't seem clear how you'd be able to tell exactly what part of the team has grown.
Furthermore, to try and understand exact details could create problems with self-organization and self-ownership, if the person trying to do the measuring is a manager or someone in a position of authority. It could cause the team to defer to the manager or think they're doing something wrong, or it could cause them to stop experimenting and keep doing whatever it was a manager or person of authority identified as the single reason for growth (even if it wasn't the sole reason).
Lastly, if the team discovers a manager or authority figure is focused on their velocity, they may try to game that metric. Additionally, if we showcase velocity to senior managers, and those people in power then observe velocity drop for whatever reason, they may be more likely to interfere with the team than if they were never exposed to this metric in the first place. Some Certified Scrum Trainers, such as Michael James, creator of Scrum Training Series, suggests that velocity is instead best used for release forecasting, to show how many features might be released in a 3 to 6 month period or at some point in the future. This is less likely to create the same problems listed above, since a good product owner could create a release plan based on a range instead of exact measurements.
