• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
  • salvin francis
  • Frits Walraven
  • Piet Souris

Useful Metrics Across Mutliple Scrum Teams

Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My company has standardized the scrum process and tools throughout the company including things like the start and end date of each sprint so that all iterations for all scrum teams start and end at the same time. Although they don't always share the metrics with us, it is my understanding that management looks at various metrics that they collect. It seems to me that some metrics are reasonable and some are pretty crazy. I think that comparing team velocity across scrum teams doesn't make much sense since each team calibrates their points a little different. Of course, the company has some general guidelines for small, medium, and large stories (3, 5, and 8 points), but I don't think the sizing of stories can be standardized enough to make cross team comparisons useful. However, process metrics, such as the number of stories planned vs completed per sprint seem to make some sense to me. However, this seems to encourage us on the scrum teams to plan very conservatively. Since we know that management is looking at this, we do not commit to more that we are absolutely sure we can complete in each sprint. This results in us always completing our stories for the sprint early. We then start work on stuff for the next sprint or whatever we think is useful. Maybe that is the way it should work or is not?

Posts: 16042
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general, you're right about making comparisons across teams -- one team's point may not be the same as another team's point. If the point sizes are consistent across teams, which it sounds like it may be in your case, then maybe it's useful to compare across teams. What does management do with those metrics though? What they do with them also plays into whether or not the metrics tracking makes sense. If it's just to see if one team is more productive than another, then I would say that's not the way it should be. Teams are made up of people, not robots. Different people will have different rates of solving problems. Heck, depending on the prevailing situation, the same person may not even solve solve the same problem the same way every time. There are many variables, both internal and external, to the person/people working on the problem so using story points to measure productivity is not encouraged.

The advice that I pass on to teams is to care more about your point trends rather than the point totals. If you completed an average of 10 story points in the last three iterations and then only do 5 points in this iteration, then something might be going on that the team or the scrum master or product owner needs to address. Point estimate metrics should be used to help spot problems and make improvements.

Remember too that points are used for estimation and estimates are imprecise by nature. That's another red flag, when points start getting used as precise measures. Some teams even abandon story point estimation after a while because of the problems and chaos involved when people can't agree on how to use them properly. In fact, there's actually a growing push for #NoEstimates -- you just break stories up into manageable chunks and iterate.

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic