Your opinion matters! Please fill in the InfoQ Survey!

Scrum Extensions "Suspended"

| by Christopher Goldsbury  Followers on Jul 10, 2012. Estimated reading time: 5 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Scrum extensions have been “suspended”.  That’s the most recent communication from on the community proposed, but controversial, new adjuncts to the scrum methodology.   Infoq’s coverage of scrum extensions started in late 2011 when announced they would accept context aware modifications to the original scrum process defined by Ken Schwaber and Jeff Sutherland.  Since that time InfoQ has kept regular quarterly updates on  ( 2011 4th Quarter Update, 2012 1st Quarter Update ) on the evolution of Scrum extensions.

The news of the suspension was sudden and beckons the question “why?”.   Officially, according to the website:
“Organizations new to Scrum or struggling in adopting agile practices can benefit greatly from the wisdom and guidance of more experienced agile practitioners. Scrum extensions were proposed as a mechanism for delivering that guidance through community-vetted documentation of proven effective practices.
Although we at recognize the demand for such guidance, we have learned that extensions are not the desired way to provide it. We are grateful to those who proposed extensions to the community. Accordingly, will be happy to continue hosting the extensions that were proposed albeit as whitepapers, not endorsed extensions to the Scrum framework.”
But there can be little doubt that controversy enveloped the idea of scrum extensions from the outset.  The yahoo message boards covering the proposed extensions contained one poignant debate over the “Planning Card Game”, a proposed Scrum extension, which may have been the catalyst for the eventual downfall of Scrum extensions.   Some excerpts covering that conversation, featuring many prominent agile coaches and practitioners, including Ken Schwaber, are copied here.  
Mark Levison voicing his opinion on scrum extensions:
I'm deeply troubled by all these proposed extensions to Scrum. It feels like we're going down the path of RUP. I.E. here is a list of great practices, tune to fit your needs. The problem is that RUP novices tend to do many/most of the practices. Whereas the idea was to do a few. When I teach Scrum - I say early on: "Scrum is Simple and Incomplete". I go on to mention User Stories and Estimation (as per Mike Cohn etc). However I don't think they need to included in "Scrum" even as extensions. It seems like we're starting to tinker with a successful simple system. Here there be dragons.
Ron Jeffries echoing Mark’s sentiment:
I strongly object to the "Scrum Extensions" effort, but for somewhat different reasons. My reasons include:
The Extensions notion is clearly intended to give control over what is, and is not, OK in Scrum. This is not good for anyone, even
So far at least, the Extensions have not given credit to the original sources, nor to the many people who have been doing them for years. They often seem, in addition, to have been written up by people who have never really used them. This is a unique combination of disrespectful and ineffective.
To be successful in Scrum, teams need to do many things that are not specified by Scrum. The fundamental assumption of Scrum, self-organization, is that teams must, can, and will figure out what is best for them. The Extensions notion is in direct conflict with self-organization and is therefore damaging to the Scrum concepts and practice.
By blessing certain activities as "Extensions", other activities are at least implicitly not blessed. Yet there are many activities that are important and far more valuable than, say, this ripped off notion of card planning. The Extensions idea is more likely to stultify teams than it is to help them.
I like planning and estimating with cards, if one must estimate. (I do think estimation is usually a bad idea in actual practice.) I don't think anyone needs a Scrum Extension to try it nor to succeed with it. So far, all the proposed Extensions are like that: well known ideas that are better described elsewhere.
Ken Schwaber:
When Jeff and I first published Scrum, we put a number of practices in it, such
as release planning, format of the Sprint Backlog, and how to best structure the
Sprint Planning meeting. As people used Scrum, many devised alternative
practices that are also effective. As these practices emerge and prove to be
effective, we've been removing our "starter" practices from Scrum. This
encourages practitioners to use the most best of available practices for their
purposes. However, that leaves no guidance other than books, training, and
We decided that a practices model, called extensions, would help Scrum
practitioners. We call the practices Scrum extensions since we are Scrum
centric. While these practices are not specific to Scrum. Scrum uncovers the
problems that result if the Scrum Teams are not competent in using one or more
of them. When used intelligently, these are practices that should increase the
probability of developing high quality, valuable software while managing risk
and predictability.
These practices certainly will not be perfect (what is?). However, they will be
powerful, useful and instructive. They will evolve across time. We will either
attribute them correctly in the initial publication or later when notified of
the correct author. We will certainly attribute planning poker to James Grenning
and help people understand that the numbers in the Fibonacci set are the sum of
the prior two numbers (1,2,3,5,8,13,21,34 ...).
These will be practices that we and people in the Scrum community have used and
we think are useful. We will publish and recommend them to the Scrum community
after an edit/review process.
I feel a need to state again: these extensions are not part of Scrum. They are
software development best practices whose need Scrum exposes. When I go into a
paint store, there are pamphlets that recommend how to paint clean edges, how to
remove old paint, and how to fill holes. You can paint without them, but the
results may not be desirable. The same relationship exists between Scrum and
software development practices.
All of have observed that our profession needs help, every bit that it can get.
I thank everyone for attributing good intentions to this effort.
In the end it appears that those against Scrum extensions convinced the leadership.  Brett Wortman’s comment probably typified the perspective of  many:  “The charm of Scrum is its simplicity and its incompleteness. That's why it works so well.”.   Still I’m left with this question: did the community lose a chance to augment and evolve Scrum or was it best to kill this experiment before it took flight?  And even further…how will this decision affect emerging ideas like a scrum pattern language?


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

My comment about Mike Cohn by George Dinwiddie

My comment about Mike Cohn was taken from a discussion on the scrumdevelopment list ( It was not intended to cast any aspersions on Mike Cohn. Instead, it was offered as a possible reason why the scrum extension under discussion was called "Planning Card Game" instead of "Planning Poker."

The quote here, taken out of that context, is easily misunderstood. My quick email in response to Laurent's speculation was not edited for clarity, as I would have done for an article. I don't even know why those two quotes are included, as the name of the particular extension has no bearing on the creation or suspension of "Scrum extensions."

By the way, Mike Cohn assures me that he has no intention of preventing others from using the term "Planning Poker." His trademark was a protection against someone else, with less pure intent, gaining a trademark first.

Re: My comment about Mike Cohn by Mark Levison

George - what quote I can't find the reference.


Whitepapers still exist by Mark Levison

Chris - you close the item with the question: "Still I’m left with this question: did the community lose a chance to augment and evolve Scrum". No. has promised to publish whitepapers. This seems like the right level - it makes clear that these are ideas can be useful in Scrum. However it also makes it clear that they're not required.

Mark Levison
Certified Scrum Trainer | Agile Pain Relief Consulting

Scrum has always been a pattern language by Jeff Sutherland

Scrum was a pattern language before the Agile Manifesto existed. See Pattern Languages of Program Design 4 (Software Patterns Series) by Neil Harrison (Editor), Brian Foote (Editor), Hans Rohnert (Editor) Addison-Wesley Pub Co; ISBN: 0201433044, 1999. Mike Beedle led the effort and Ken and I were coauthors of the Scrum pattern language paper. You can download it for free at

The extensions were an attempt to do something similar but was fraught with controversy. In addition, the few extensions proposed were not reviewed by scrum experts using the patterns process which has been developed over the last 20 years. This requires extensive review by both scrum and patterns experts and face to face editors workshop with these experts before anything would even be considered for publication. Mike Beedle and I have been working with Jim Coplien and for years in workshops on updating and extending the Scrum pattern language. participated in our last workshop in May in Denmark along with many other companies, government organizations, and universities.

The patterns process for software is owned by the Hillside Group and is an effort that is fully sponsored by the Hillside Group with two of the founders of the patterns movement assuring that a very rigorous process is followed involving a global group of Scrum experts. Having written several of the published Scrum patterns that I use regularly in my Scrum training, I can say that pattern writing requires a lot of work, is a community effort, involves a lot of critical feedback by experts, that cause writing and rewriting the pattern multiple times before it can even see the light of day.

There will eventually be a book on Scrum patterns similar to Organizational Patterns of Agile Software Development by James O. Coplien and Neil B. Harrison (Jul 26, 2004). It will take about seven years to write this book and we are only about two years into it. This kind of effort requires a global consortium of leading experts in the field over a very extended time period.

It should be noted that a pattern is not an extension to Scrum. It is a complex of problems, forces, solutions, and effects that must be seen in action is at least three different organizations. A pattern proposes a solution to a commonly seen problem and may or may not be useful to anyone doing Scrum. If they have a specific problem, they might try a proposed solution that has reliably worked on multiple occasions in multiple organizations. See for a description of all things you would ever want to know about patterns.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you