Ken Schwaber and Jeff Sutherland Release Updated Scrum Guide
- Share
-
- |
Read later
My Reading List
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.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Big step forward
by
Jens Meydam
Re: Big step forward
by
David Bulkin
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
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
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
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
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
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
Re: Big step forward
by
Mj Patterson
Kind Regards,
~ Mj
Re: Fantastic that commitment is replaced by forecast
by
Klaus Bucka-Lassen
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.
Educational Content
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login 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