For most all games and activities, rules are published and considered separately from strategy. For example, the rules of chess say nothing about the various strategies that have evolved for playing the game; so should it be for the rule book of Scrum. With this distinction in mind I am proud to have been working with Ken Schwaber, Jeff Sutherland, Jim Coplien, Scrum.org, and other advisors and contributors in producing a significant revision to the Scrum Guide.
The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on. Strategies for succeeding with Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those revising the Scrum Guide, this meant all tips, optional practices, and techniques should be removed from this document. This was done along with refining language to correct some common misunderstandings about Scrum.
While nothing about the Scrum framework itself is fundamentally changed, some long-needed clarifications were made. Each will likely deserve its own post in the future, so I will simply note them here.
- This is the role structure of Scrum with proper names shown. The careful observer will note the change from ?The Team? to ?Development Team?. This is the team of people performing the work of creating an Increment.
- Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team forecasts the work it believes will be done, and that forecast changes as more becomes known throughout the Sprint. To do otherwise is to ignore the cone of uncertainty at play during a Sprint.
- Burndown charts are not required. Neither Sprint nor Release nor Product Backlog burndowns. Those graphs are merely very effective at doing what is required, which is:
- Remaining work for a Sprint is known and summed daily.
- A trend of work remaining is maintained throughout the Sprint.
- Release Planning is not a required component of Scrum. Most organizations will certainly benefit from it, but it isn?t a core component of Scrum.
- The Sprint Backlog consists of the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of ?Sprint Backlog items? although that technique is easy to implement and the items themselves can make a great plan.
- Backlogs are no longer said to be ?prioritized?, but ?ordered?. For some this is a non-issue, but for others it is a hill worth dying on. I?ll write about why in a later post.
Although none of these notions are terribly radical, they help make clear the actual definition of Scrum. This clarification also makes clear complimentary practices that are useful, but will likely evolve separately from Scrum itself.
Read the updated Scrum Guide here.
Nice summary, David!
In practice people are most uncomfortable with calling everyone on the team ‘developer’. Becoming frustrated with loss of Role Identity claiming that scrum is disrespectful to specialization. Usually this disrespect is felt by programmers who prefer to be called developer because they aren’t simply programmers and by testers who have built up years of expertise in testing. In many shops there is prestige in a title of QA Analyst or Developer or Sr Developer the denotes functional expertise. What comments would you have for such people on a team?
Second clarification I would request is around the ‘values’ of scrum. There is no mention of them in the guide, but they have been guideposts for me every day. When there is doubt about a rule/process/practice we can rely on the scrum and agile values to come to a good conclusion.
Specifically, how does “Commitment” play into scrum now that making a sprint commitment is no longer a purpose of sprint planning or making adjustments to make those commitments is no longer a purpose of the daily scrum.
Thanks,
@facebook-524628599:disqus Good questions, both. I will make sure to blog on each of these subjects soon.
@facebook-524628599:disqus Good questions, both. I will make sure to blog on each of these subjects soon.
HI James, you are unfortunately right! I personally believe the reason behind removing the notion of titles or role identity in Scrum is to effectively remove a constraint in the team to allow the teams potential to be realised, today I may be the best tester but tomorrow I may be the best developer;
In my opinion traditional organisational cultures which use the idea of promotion to a role to enhance a persons paycheck fails to really satisfy the majority of developers myself included. I am a developer of 20+ years experience and am proud to be called one even though I could regard myself as tester/architect as these are all areas that I have specialised in for a period of time. I think we have to change the way people think about the value of roles so that all members are valued for their potential contribution to the team rather than being it simply based on status and a sense of power or superiority.
i have the info about the many guides but for the first time i got the info for the type of guide given above that is awesome in many ways to explain the reality of the document that can be availed in the real media!
regarded@work experience insurance cover
Hmm great way to ask a interesting question but i have no answer you please read my site i will tell you at this please hurry… I am waiting your reply please don’t mind …. 🙂
Keep it up guys i always with you author great effort i seen here … finding work experience
Sprinters should develop overall fitness in a way that does not involve jogging. They should however BE ABLE to jog for a long distance without a problem. Overall fitness can be acquired through dance, medicine balls, skipping etc. A variety is best. Progressive circuit training is great.