We recently started using story points in our agile process, which is awesome. Because of this we are getting estimates for certain tasks and getting an idea of our velocity.

However, I am curious whether story points can or should ever be used for measuring growth of the team?

So, for the classic example, let's say we have a group of developers who agree that an issue or project is worth 21 story points. For some of the developers it will take them 3 days while for the other developers it will take them 6 days.

At some point in time, while the complexity of issues remain the same, the productivity of the developers will naturally increase because of their familiarity with the codebase, etc. Is there an effective way of measuring growth in the team with story points? Or perhaps this is completely the wrong way of doing it.

1 Answer 1


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.

  • Correct me if I understood wrong -- so story points really shouldn't be about measuring "velocity" per se and should simply be a form of forecasting how many features can be released in a given period. Or even if it did somehow suggest velocity, it isn't a metric people should deeply look into.
    – aug
    Commented Mar 10, 2016 at 8:23
  • 1
    I don't think it's something outside people should look into too much. Sure, it measures velocity, but if you try to incentivize it going up, you may not necessarily get the result you're looking for. It could result in something else suffering, like quality, for instance. Instead, I suggest letting velocity be something the team uses to know what they can commit to next sprint and not something where they feel like senior managers may get upset about, f the number doesn't appear big enough.
    – jmort253
    Commented Mar 11, 2016 at 11:14
  • I'd say that ideally, the velocity goes up during the first bunch of sprints and then stabilizes as the team becomes familiar with the codebase and removes barriers to productivity.
    – Cronax
    Commented Mar 15, 2016 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.