In a presentation about Hyperproductivity and Shock Therapy, Jeff Sutherland mentioned that Hyper-Productivity is at least Toyota level of performance which is four times the industry average. According to him, teams doing Agile development the right way, see a 300% improvement in 3 two-week sprints. In a recent discussion on the Scrum Development group, members debated whether it is both fruitful and possible to accurately measure productivity across sprints. Also, whether it is possible to identify if a team has reached hyper-productive state.
Adam Sroka suggested that it is difficult, if not impossible to measure productivity across sprints. Most of the times teams base the productivity gains on story points, which does not remain constant across sprints. According to him,
Story points are not necessarily comparable, although they seem to converge over time (e.g.five story points in iteration one is likely not comparable to five story points in iteration five. However, five story points in iteration five likely is comparable to five story points in iteration six.) So, the increases in productivity we see through the course of an Agile project are anecdotal. We have seen them. We know they exist, but we lack any definitive way to measure them.
Tobias Mayer agreed to Adam when he mentioned that,
This "hyper-productivity" measuring is mostly a waste of time -- and a way of selling snake oil. Estimation of stories is not a constant thing; teams change the way they do this over time as much as they improve their ability to deliver. And as Adam points out comparably complex stories require less and less effort as we get better.
I think such "quantified" claims do a disservice to Scrum, and as the original poster points out, if you set your baseline low enough, everything can appear as hyper-productive. What if a team completed nothing at all in sprint one? Then getting one story point done in sprint two would represent an infinity% increase. It is all nonsense.
Joseph Little suggested that though a lot of talk about hyper-productivity is gush, hyper-productivity in itself does make sense. He suggested that in order make improvement the team should know their velocity. He agreed that the velocity might change with the iterations and so would assigning different story points to a similar sized story across sprints. The way to manage this to average out and consider the average velocity over 3 sprints rather than one. The next challenge should be to double this velocity by making minor and major changes in the development process so that the impediments are reduced considerably. According to Joseph,
Let me be a tad blunter: Things are so screwed up in SW dev, that doubling a team's productivity is not that hard.
Roy Morien added that it is very difficult to measure personal or team productivity mathematically. Hence, instead of trying to achieve the measurement part, teams should focus on delivering useful, working software and try to improve on what they did in the last sprint.
On similar lines, Adam Sroka mentioned that instead of wasting time in measuring productivity effectively and analyzing whether the teams have reached the hyper-productive state, teams should focus on the following
- Are we delivering working software that is valuable – continuously, every iteration?
- Are we expending effort in a manner which is sustainable? Can we continue to deliver at this pace indefinitely? Can we improve?
- Are we wasting effort on things which do not contribute directly to the delivery of value? How do we eliminate such waste?
Thus, throughout the discussion, most members of the group suggested that there are more important considerations to Agile development than just comparing numbers across sprints to see if a state of hyper-productivity has been reached. Moreover, since there is no standard way of gathering numbers across sprints, comparing them becomes a futile excercise.