Skip to main content

Differences between Scrum Guide & Scrum Primer

Last post 10:14 am November 29, 2012 by Michael Jebber
7 replies
11:48 am November 28, 2012

Hi all

There seem to be some differences between the latest Scrum Guide (Oct 2011) and the latest Scrum Primer (version 2). These differences may cause confusion and annoyance, especially given that the subject matter has found its way into certification exams.

Example: The Scrum Guide says that only a Product Owner has the authority to cancel a Sprint, but the Scrum Primer says the Product owner or the Team can cancel it. Even more confusingly, Ken Schwaber says in "Agile Project Management with Scrum" (2004), Appendix A, that the ScrumMaster can abnormally terminate a Sprint. This question appears in the Professional ScrumMaster self-assessment.

Example: The Scrum Guide says that the recommended Development Team size is 6 plus or minus 3, while the Scrum Primer puts it at 7 plus or minus 2. Again, this is a question that appears in the Professional ScrumMaster self-assessment.

Example: The Scrum Guide says that the Product Backlog is an ordered list of everything needed, including "all features, functions, requirements, enhancements, and fixes". But the Scrum Primer says that it might "possibly" include known defects, "if there are only a few problems"...otherwise they are usually handled by "a separate defect tracking system".

Do these differences represent a growing divergence in recommended practice between and the Scrum Alliance, or am I reading too much into the differences I see? I have the distinct impression that the Primer is more a product of the Alliance while the Guide is more a product of I'd welcome being corrected on that point.

Anyway, if anyone spots any other dissimilarities in this core material, please could they be posted here? I expect there will be others, and as I have pointed out, they might cause people to stumble in certification exams.

01:37 pm November 28, 2012

> I have the distinct impression that the Primer is more a product of the
> Alliance while the Guide is more a product of

Spot on.

On Wed, Nov 28, 2012 at 11:48 AM, <> wrote:


02:23 pm November 28, 2012

(Disclaimer -- I did a quick review of the 2.0 SP(Scrum Primer), but I'm familiar with previous versions)

At this point in the deviation between the two docs, I think it's very difficult and time consuming to do apples to apples comparisons. The differences between "SA Scrum" and " Scrum" are also beginning to diverge in significant ways.

AFAIK, the SP is not an official part of the SA curriculum. The one I found on the SA web site is version 1.2.

Of course, those of us affiliated with (I'm a Professional Scrum Trainer certified by believe very strongly that the Scrum Guide is the official definition of Scrum. I also happen to be believe it is the most advanced definition, as several updates and improvements/advancedments have occurred in recent years.

03:14 pm November 28, 2012

> Spot on.

Oh dear, I was afraid you were going to say that.

03:19 pm November 28, 2012

> I have the distinct impression that the Primer is more a product of the
> Alliance

Exactly. And even more - Prime is one of recommended sources for CSP preparation. But I agree it's not an official Scrum Alliance definition. Alliance has different strategy and vision - each CST has own Scrum which he/she brings to the official training class. I have recently talked to one of the CST (Sergey Dmitriev) and he emphasized that point of view. trainers (and Bradly can correct me if I'm wrong) can only teach the Ken's Scrum definition.
The good news is that many of the CSTs consider Scrum Guide to be an official version.
To prove that you can find several articles on ScrumAlliance with links to the Guide.
For example -
Next, have you read "Essential Scrum" written by Kenneth (by the way, one of the best books I have ever read)?
Through the book you see the endless links to the Scrum Guide.
Maybe it's my own point of view, but the Scrum Guide has already become an official definition of the Scrum de facto.

03:41 pm November 28, 2012

Hm... I have just noticed that Scrum Prime is owned by Scrum Foundation headed by Jeff Sutherland.
I thought Ken and Jeff are both the authors of the Scrum Guide.

The Scrum Foundation (formerly Scrum Training Institute) is the premier global provider of certified Scrum training and consulting. Founded by Jeff Sutherland, the co-creator of Scrum, and leading international Agile experts Gabrielle Benefield, Pete Deemer and Jens Scrum Foundation provides a complete solution for companies seeking high-impact results from Scrum and Agile development.

Therefore, it's not owned by ScrumAlliance.
Would be very helpful to hear what Ken would say about that.

07:37 pm November 28, 2012

Prime is one of recommended sources for CSP preparation.

I think you meant:

*The Scrum Primer* is one of recommended sources for CSP preparation.

Yes, and No. The 2010 version of the SP is a recommended resource for the CSP prep. Further, the current CSP examination is going away very soon, according to the Scrum Alliance -- there will supposedly will be a new cert program based on... you guessed it.... sitting through a class.

10:14 am November 29, 2012

Although informative, I find the responses to this thread somewhat disturbing. Ian’s question is more than valid, however, the tread moves quickly from the original inquiry about some differences, to who owns the official version of Scrum. In my option, the more we as a community move towards “Donkeys and Elephants” when it comes to Scrum, the farther Scrum moves from an agile framework to a more rigid one. We should be careful about how prescriptive we are as a training community in some areas.

Take for example the recommended team sizes. Let’s re-ask ourselves: “What really determines a products proper team size (and the product should be considered when deciding this)?” Several factors come to mind immediately:

1. Consensus in a Timely Manner: We have basic general need to gain consensus, in a timely manner, on a regular basis within Scrum teams. It’s been my experience over the last 5 years using Scrum (both properly and improperly) than any group with varying skillsets and subject matter expertise larger than nine makes gain consensus in a timely manner nearly impossible. This is true for Scrum teams, stakeholder groups, groups of PO’s working on complex integration projects, and any other gathered group. We have service groups, Enterprise Help Desk, Tier II Support, Release Management, and others who use Scrum to manage their work and perform their duties. In these cases, the teams have been able to move forward quickly with a larger group since the members on the team are all of like background, skillset, and SME. Again the focus is not just consensus, but consensus in a timely manner…remember we are time-boxed and need to deliver what we promise on-time. Our most “productive” groups have been 5-7 people and no more...why? They consistently provide more value to their customers on a regular basis with consistently high quality than teams which are larger.
2. The Team’s Skillsets: Different products are going to require different skillsets. Yes, utopian Scrum has every team member owning all the skillsets needed to do every task on the backlog themselves. Ok, how many of you really live in this world today in your companies? It’s something we all work for of course, but it’s like reaching infinity, or the speed of light, or the perfect golf game, you can always get a little closer to the goal, so “what is good enough”? Team skillsets should be considered when determining proper team size for a product.
3. The Product: Depending on where a product is in its own lifecycle, and what the company/customer requests of the PO, different skill sets may or may not be necessary at different points in time. Maintaining a consistent, focused team on the product is always the best way for function, but some products may require a specialist’s assistance for several or many sprints until either the products team is well-enough versed on what to do moving forward, or the specific requests needs are met, and further maintenance of the new functionality can be handled by the now more experienced original team. Moreover, some of our Scrum Teams “products” are the services that they provide to the organization. These teams have a narrower focus on what is needed to deliver a high quality service and have shown to not be affected as much by team size as development teams are.

So I believe just talking about the numbers without getting in deeper about what they represent is prescription without diagnosis and doesn’t carry much value on its own. THIS is my concern with what Ian brings forward in this thread. How do the two main bodies that exist today truly assess someone’s knowledge about some of these areas while keeping true to the essence of what we are all trying to achieve with this framework in the first place? I think what is out there is a start, but we are nowhere near the perfect golf game yet…

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.