Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

Hyperproductivity in Scrum

  • submit to reddit
Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.

According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:

"We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience."

Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:

"The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of points completed is the baseline velocity."

When I first read that, I was like "what am I missing here". Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn't strike me as a very fair metric, you'd think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.

But here is their key assertion that supports the measurement:

"At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative"

I don't know about you guys, but I'm kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I'm not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren't. It might also be interesting to see the team stabilize first, and then see how much better they'd get by systematically removing impediments.

These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?

BTW - I loved the image here... seemed pretty much with the Shock Therapy theme. Check out the artists website at
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Sheldon Porcina replied on Tue, 2010/06/29 - 12:37pm

I don't think you are missing anything.  I have the same thoughts.  My opinion is that the statements made imply much.

In my experience productivity depends on the team and the environment.

For example, assume a team is full of talented, experienced people.  In a waterfall environment where they may have less control over the inception & direction of their work products, they may be less productive than in an environment where they have greater control.  Scrum provides some additional control, but that control can also be achieved without Scrum.  Scrum is no guarantee of greater productivity.  Like Schwaber said "Scrum shows you the problems, it is up to the team to fix them" (slightly paraphrased).

On the subject of productivity of a newly formed Scrum team, I find the first few sprints are 'chaotic' and sub-optimal.  Often because there are several new discoveries of work and issues, and the team needs time to 'gel' (define roles, responsibilities, project on-boarding, etc).

To make a fair comparison, I would like to know:

  1. Was it the same team that migrated from waterfall to Scrum?
  2. Was the work the same size and effort between the two methodologies?
  3. What were the metrics used to determine productivity?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.