• 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 ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Useful Metrics Across Mutliple Scrum Teams

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • 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?

Nathan
 
Sheriff
Posts: 13679
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • 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.

 
This will take every ounce of my mental strength! All for a tiny ad:
create, convert, edit or print DOC and DOCX in Java
https://products.aspose.com/words/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!