Differences between Scrum Guide & Scrum Primer
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 Scrum.org 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 scrum.org. 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.
>
> I have the distinct impression that the Primer is more a product of the
> Alliance while the Guide is more a product of scrum.org
Spot on.
On Wed, Nov 28, 2012 at 11:48 AM, <ScrumForum@scrum.org> wrote:
>
(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.org 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 Scrum.org (I'm a Professional Scrum Trainer certified by Scrum.org) 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.
> Spot on.
Oh dear, I was afraid you were going to say that.
> 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.
Scrum.org 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 - http://scrumalliance.org/articles/367-its-ordered--not-prioritized
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.
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.
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.
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…