Ken Schwaber and Jeff Sutherland, the co-creators of Scrum, released the first update to the Scrum Guide since February of 2010. The new version of the guide focuses on the framework, rules, and ceremonies of Scrum, removing specifics about strategies and techniques. An accompanying Scrum Update Document provides a statement of refinements that clarifies some of the finer points of the Scrum Framework.
The new version of the guide is available from the Scrum.org website. The last page of the new guide, page 17, describes how the current guide differs from that published in February 2010.
This June 11, 2011 Scrum Guide is different from its predecessor, the February 2010 Scrum Guide. In particular, we have attempted to remove techniques, tips, and best practices from the core of Scrum. We will be starting a “Best Practices” compendium to offer some of our experiences later.
A separate document, the Scrum Update, provides further context on what was changed. The list of changes is specified below along with context on those changes.
Scrum has always made it clear that there are only three roles, Product Owner, ScrumMaster and Team Member. Per the clarification below those team members are all called Developers.
The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.
The plans made at Sprint Planning have often been assumed to be commitments. The next clarification makes it clear that even in short Sprints, the plan is open to modification as more is learned.
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
Over the last couple of years, Cumulative Flow Diagrams (CFDs), have often supplemented or replaced traditional Burndown charts to monitor progress. Per the clarification below, CFDs, Burndowns, and other tracking approaches are equally valid as long they report progress on remaining work on a daily basis.
Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that:
- Remaining work for a Sprint is summed and known on a daily basis.
- Trending toward completing the work of the Sprint is maintained throughout the Sprint.
Although the majority of teams do some form of release planning, per the subsequent clarification, release planning is not required in the Scrum Framework, which especially makes sense for short lived efforts.
Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.
As more teams use electronic tools, and create complex relationships across different levels of backlog (e.g. from enterprise down to team level) the black and white distinction between Product and Sprint Backlogs has blurred. Per the clarification below, a Sprint Backlog is simply a set of Product Backlog items that comprise the Sprint along with a plan for getting them to done.
The Sprint Backlog is 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 can make a great plan. A self organizing Development Team always has a plan.
The concept of prioritization of a Product Backlog has implied that functionality was released purely in business value order, ignoring technical aspects and tradeoffs. The final clarification uses the word “ordered” instead of “prioritized” to represent a more holistic view of sequence to market.
The Product Backlog is “ordered,” instead of “prioritized,” providing flexibility to the Product Owner to optimize value in his or her unique circumstances.
Please respond with your thoughts about the new guide and how you view the clarifications specified above.