BT

Ken Schwaber and Jeff Sutherland Release Updated Scrum Guide

by David Bulkin on Jul 27, 2011 |

Scrum GuideKen 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.

Hello stranger!

You need to Register an InfoQ account or 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

Big step forward by Jens Meydam

I would say the clearer separation of goals and techniques to achieve these goals is a big step forward.

Re: Big step forward by David Bulkin

Jens,

I agree with your statement. The early feedback that I have heard is that the new version is easier to read and more appropriate for the purpose of clarifying what the framework is. I am interested in what others think, and how they vie the update document that provides clarifications.

Fantastic that commitment is replaced by forecast by Jesper Boeg

The commitment aspect of Scrum has been bothering me for years and I have always insisted that the sprint backlog should be considered a forecast created at a point in time where limited information was available about the actual work to be performed. This has gotten me into heated discussions over time and I have been told by CSTs that I just simply did not understand the concept and value of commitment. To me it has however always represented a dysfunctional aspect close to the waterfall aproach style thinking of "if we just plan in enough detail we will get predictability" resulting in stress, quality problems, information hiding and economics of scale batch optimization.

Nothing wrong with having a goal, nothing wrong with tracking your progress against that goal, nothing wrong with taking action when you deviate from that goal as long as you make sure that you understand that the goal is a direction not a success criteria. Which to me is very close to the core of Agile

Re: Fantastic that commitment is replaced by forecast by David Bulkin

Jesper,

Many in the community agree with you. They will state that we have learned, that even when we plan in very small time blocks, of less than a month, our plans are still that, plans. Reality is likely to intercede and cause us to rethink what we planned at the beginning of the sprint.

But, on the other side of the coin, there is also a lot of noise from those who are concerned that we are giving teams too easy an out. If you don't get a commitment out of sprint planning, and we just get a forecast, well, where is the accountability. Is it okay to simply miss sprint after sprint?

Perhaps the middle ground is committing to a sprint goal, instead of committing to the individual stories, as a goal provides more flexibility than stories.

What do you think?

Re: Fantastic that commitment is replaced by forecast by robert phillips

Booooooooooo! What is the issue with commitment? The notion of commitment fosters a level of ownership and responsibility within the team. The team gets to define its work, and the team also commits to completing that work. This creates a constructive relationship between the team, the product owner, and other stakeholders.

And yes, plans change, and sometimes things are even underestimated. This is understood. But I don’t see how this means the concept of commitment should be eliminated.

If a team cannot accurately plan and commit to a couple of weeks worth of work, then how can that team be considered skilled at self organizing?

Re: Fantastic that commitment is replaced by forecast by Stephen R

What is wrong with commitment? Nothing. Is there something wrong with product management or senior management beating up teams for "not keeping their commitments" because they didn't complete the 10th story but completed 9? Or a developer being told, hey, you're life is not important and those bugs from your other projects do not effect me because you COMMITTED to delivering this. I've seen this in a Scrum-By-The-Book shop (ugh) and it really, really stank.

The team should be committed to hitting their forecast, but it shouldn't be written in stone.

Re: Fantastic that commitment is replaced by forecast by David Bulkin

I think the comments from Robert and Phillip get to both sides of the coin.

In respect to Stephens' point I have seen management put too much focus on hitting the goals of individual sprints, resulting in lots of late nights and weekends, along with low quality and people who get worn down. In these cases, I generally recommend to management that they focus on release goals, understanding that sprints are stepping stones to a release.

Now in respect to Robert's point, there needs to be accountability, and a sense of urgency. If some of the sprint forecasts are off (some high, some low) but we reach our release goals, well, the Product Owner should be happy.

Re: Fantastic that commitment is replaced by forecast by Stephen R

I like David's point about focus on releases. We are currently do this with our teams (not at the Scrum-by-the-book shop) and things move much smoother. I would also recommend against trying to do a release per two week sprint. It's a velocity killer if the release isn't hitting a big read Easy button and taking a nap.

Re: Big step forward by Mj Patterson

Yes. If you REALLY want an agile graph though, you need to include all your team members. I see no metrics to do with documentation! These days that encompasses UI design, inline help, videos and the tried and true .pdf but whatever the case, the feature isn't done until the docs are. Otherwise you are not Agile. Can we see an amended, more inclusive graph please/
Kind Regards,
~ Mj

Re: Fantastic that commitment is replaced by forecast by Klaus Bucka-Lassen

My2c on why a sprint commitment generally is a good thing.

Have you had (or know anybody who has) any of those private programming projects at home? Do they ever come to an end? Own experience. If you give me an unlimited amount of time, there is a good chance I will use it.

Why? I think because a certain amount of commitment (or "positive pressure") to finish is lacking. There is always something that can be slightly improved, a new cool feature that can be added, another GUI library that can be included, a class that can be re-factored, test coverage that can be increased, etc.

To me a sprint commitment is time boxing.

Commitment to finish a certain amount of stories within a given time frame enables the team to focus on simple solutions instead of over engineered ones. There often needs to be some pressure to find these simple solutions. And if you have a good definition of DONE, the quality won't suffer.

Commitment can also be viewed as a tool for the team to fight of "whistle and bells". I have seen many senior developers designing highly complex solutions just because they can and because they have been used to do so (culture). With a constraint on how much time you can spend it is easier to call someone of.

Also, the product owner can assume that the sprint will complete as planned, if he doesn't hear anything else from the team. It's the default. Otherwise, he might feel urged to check up on the team on how they are doing on a more regular basis than what is comfortable. He might also feel that he needs to apply pressure to getting things done in time, because he himself has committed some release to the stakeholders.

One way or the other, there will at some point be pressure to finish the project. Self-applied pressure by the team committing to a sprint goal is in my view much better than external pressure. I respond very badly to goals set by somebody else.

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

10 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT