Scrum Guide Updates
inspection and adaptation
Updates have come to the Scrum Guide; here is some insight into why these Scrum Guide changes have been made.
Gone are Release Planning and the Release Burndown
The New, New Sprint Backlog
Chickens and Pigs
Ordered Not Prioritized
Commitment vs. Forecast
 |
Gone are Release Planning and the Release Burndown
Any Product Manager that has successfully delivered a product to a customer knows how incredibly important Release Planning is. Despite its importance, the 2011 Scrum Guide, published in July by Ken Schwaber and Jeff Sutherland, removes any discussion about Release Planning and the related Release Burndown chart. Professional Scrum Trainers Ralph Jocham and Henk Jan Huizer explain these changes:
Why remove items from the Scrum Guide?
The Scrum Guide, the body of knowledge for Scrum, has grown over the years to address the expanding array of questions people have about successfully using Scrum. In the recent update of the Scrum Guide, Ken and Jeff decided to remove most of the tips and strategies and only keep the basic rules by which Scrum has to be played. This may seem to be a strange choice given that there are still thousands of potential questions about how to use Scrum.
But there is a good reason for the removal of implementation strategies and tips. Simon Sinek argues that one should always start with the “Why,” and only then move on to the “How” to at last finish with the “What.” The previous version of the Scrum Guide described a lot about What has to be done. However, describing the What closes the door on alternative and possibly better approaches. In contrast, describing the Why prompts people to think for themselves about how to apply the concepts in their own unique context. Removing much of the What from the Scrum Guide also prevents copy/paste behaviors, blindly following the rules, without understanding them, just because it happened to be successful in another situation; thereby creating a cargo-cult.
This article focuses on the removal of Release Planning and Release Burndown from the Scrum Guide.
Why do we have Release Planning?
In the software industry products are commonly delivered to customers in official releases. These can be single big releases at the end of a project, or more incremental releases on a quarterly or even a yearly cycle in the case of product development. Although releases are common, they conform to the weaknesses of software development, and don’t leverage the incremental and iterative process of an Agile framework like Scrum. When Scrum is used well, potential value is created with every Sprint. But if the increment isn’t released with every Sprint, we are not delivering that value to our customers. We actively seek feedback from users, so why don’t we make it easier by releasing the increment from Sprint to Sprint?
The practice of software releases exists because it is not always practical to constantly deliver what is being built. Scrum requires that a product Increment at the end of a Sprint be potentially usable. This does not mean that it is necessarily useful. So, there is often a need to batch usable Increments from subsequent Sprints into something that is potentially useful for a customer.
Unfortunately, some organizations use releases to compensate for bad development practices. A usable Increment is one with no “undone” work associated with it at the end of a Sprint. If teams are unable to create truly usable Increments, the remaining work (testing, documentation, user acceptance, etc.) are done as part of the release process - sometimes referred to as the stabilization phase. In this case, the release plan codifies the acceptance of the poor development practices, and makes it incredibly difficult for a Product Owner to effectively plan when a release will happen.
However, even if a release is constructed of usable Increments, and is potentially useful for a customer, a lot of things have to take place for a customer to actually get value from it. This process of integrating a release in order to extract value is called absorption.
To readily absorb a release, customers may have to go through extensive installations, trials, pilots, rollouts, training, certification, and a host of other processes before the release can create value. Being aware of, and actually planning for, these activities that need to be done to help customers extract value is why release planning is done. This is the reason why the previous Scrum Guide included release planning.
Why do we have Release Burndowns?
Scrum is an empirical framework built upon the three pillars of transparency, inspection and adaption. In order to adapt we have to inspect, and in order to inspect we need transparency. We use a burndown because it provides transparency into how we are doing over a given time frame. It allows quick answers to questions like, “Are we on track, are we ahead, or are way behind?”
Scrum is used in complex environments, like product development, where circumstances change on a daily basis. Requirements change, technical challenges are encountered often, and the organizational environment changes on top of that. Scrum accepts that changes are part of the process of complex software development and embraces them. In order to deal with changes, we need precise up-to-date information.
The release burndown provides exactly this piece of information towards a release goal. The inspection opportunity the release burndown allows provides the precious ability to adapt immediately when changes are realized. It gives the Scrum Team the chance to ask the hard questions early, instead of waiting until the week before the planned release date.
Why has Release Planning been removed from the Scrum Guide?
The answer is short and simple: it is possible to successfully use Scrum without using release planning. Not needing release planning may actually be a positive indicator of a product’s health. Scrum is intended to deliver value to customers continuously through short iterations. Using releases may actually delay the delivery of value, customer feedback, and return on investment (ROI). With mature development practices and excellent rollout strategies, the delivery of value can take place every Sprint.
Is Release Planning no longer allowed in Scrum?
Release planning is still incredibly valuable in many cases. It is often difficult to deliver a complex business solution in the short time frame of a single Sprint. Sometimes extensive test periods are needed to satisfy rigorous quality requirements. Large enterprises sometimes require infrastructure changes. And sometimes customers don’t like frequent releases because they actually create more pain than value. In these scenarios release planning is a valuable activity, a way to come up with a plan, a roadmap of what can be expected after a couple of sprints, and what will be part of the release and what won’t.
Why has the Release Burndown been removed from the Scrum Guide?
As Scrum no longer requires release planning, it makes no sense to require a release burndown. Scrum strives to make the process of software development and delivery transparent. A burndown can be incredibly useful in supporting this. But, there may be other ways to achieve this same objective. By removing the guidelines on What to do, Scrum can benefit from future innovations.
The 2011 Scrum Guide returns to its roots. Less can be more! But don't be fooled by 16 pages of rules; the game of Scrum is simple to understand, but difficult to master.
|
The New, New Sprint Backlog
The 2011 Scrum Guide, published earlier this month by Ken Schwaber and Jeff Sutherland, makes some bold changes regarding the definition and structure of a Sprint Backlog. Professional Scrum Trainer David Starr explains these changes with help from Professional Scrum Trainer Ryan Cromwell:
The 2011 Scrum Guide makes some bold changes regarding the definition and structure of a Sprint Backlog. Clarity about Sprint Backlogs is long overdue, and these changes should help many who struggle with the concept.
The Scrum Guide 2011 states:
The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.
This is a significant departure from earlier understandings of a Sprint Backlog, and opens new possibilities for those practicing Scrum. This less prescriptive approach enables Scrum Teams to experiment within the Scrum framework and find the right planning model that works for them. This ultimately puts the Scrum Team in charge of their own process and allows Scrum itself to flex and accommodate advances in technology and practices.
What was the Sprint Backlog, anyway?
Several times during the last year, I asked people knowledgeable in Scrum (even published experts) to have a look at the following diagram, showing the decomposition of Product Backlog items to Sprint Backlog items. This simple model is a classic way to envision the work within a Sprint.
I then asked viewers to draw a circle around the Sprint Backlog.
“What do you mean?”, they asked.
“Just draw a circle around the Sprint Backlog,” I requested.
After the inevitable pause, the person would draw on the paper and hand it back having chosen what they believed was the “correct” definition of a Sprint Backlog. Variations included those shown below.
|
|
|
|
|
A Least popular |
B Most popular |
C Chosen by Ken Schwaber |
This obvious confusion around the definition of a Sprint Backlog had significant implications. I have even spoken with a very capable Scrum trainer who chose B and invented a new term for the PBIs selected for the Sprint.
Of course, applying the definition from the 2011 Scrum Guide, we can see that C is the correct choice and that the plan for realizing success in the Sprint was represented by the Sprint Backlog items, or tasks, themselves. That is to say, the tasks were the plan.
This technique is the traditional way Development Teams sum remaining work and track progress toward completion, but prescribing this as the only way to do so is overly restrictive.
Compounding Issues
Given the disparity in responses, something clearly needed to be done to ensure a common understanding of a Sprint Backlog. There were other discussions underway that would also have an impact on the issue as the new Scrum Guide came together.
Simpler Work
Many Scrum Teams have found themselves in a Sprint Planning Meeting faced with a bug or some other small-sized Product Backlog item being considered for inclusion within a Sprint.
The canonical example of something like this is a label change on a page or form. This is arguably one of the simplest possible changes a Development Team might be asked to implement. The inevitable question asked by a Development Team member accepting this Product Backlog item into the Sprint is, “Do we really have to make a task (Sprint Backlog item) for this?”
Until now, the answer was typically, “Yes.” Sprint Backlog items were required for each Product Backlog item. This means teams could often end up with a small Product Backlog item and a single corresponding Sprint Backlog item because “that’s how it’s done.” Typically, this was to satisfy some electronic tracking tool or over-prescriptive Scrum Master, but the wasted effort of creating and managing the placeholder Sprint Backlog item was spent nonetheless. In this all-too-common situation, Scrum over-prescribed a solution, thereby inhibiting self-organization of the Scrum Team.
Implicit in the 2011 Scrum Guide’s definition of Sprint Backlog is the notion that teams may do what makes sense in situations like these. There is no specific “that’s how it must be done” with regard to creating a plan for delivering Product Backlog items selected for the Sprint.
New Ways of Defining Done
To further complicate the question of “What is a Sprint Backlog?” many teams have been successfully experimenting with new and exciting ways of representing “Done” within a Sprint.
One emerging technique is seen in Development Teams using ATDD (Acceptance Test Driven Development), a technique in which all requirements are represented by automated tests that must pass in order to be considered complete. For teams using ATDD, might a valid Definition of Done for Sprint Backlog items simply be that all associated tests created during the Sprint must pass? This approach is growing in popularity as tools, knowledge, and experiences mature in ATDD and BDD (Behavior-Driven Development).
In some less than thoughtful teams, the Definition of Done for a Sprint is seen as the completion of all tasks, or Sprint Backlog items. This letter-of-the-law approach to defining done takes attention away from the Sprint Goal, delivery of which is the true Definition of Done for a Sprint. “Perhaps,” some teams conjecture, “the only real measure we need is completion of the Sprint Goal itself.”
Conclusion
The 2011 Scrum Guide explicitly enables Development Teams to select Product Backlog items for a Sprint and create a plan for delivering them that may be unique for the Development Team. This empowering flexibility enables creative and intelligent decisions that make sense for the Development Team in planning and delivering the Sprint Goal. The plan itself might come in the form of an automated test run report, a Sprint Goal measure, or some other new way of seeing the work that has not yet even been discovered.
The 2011 Scrum Guide offers some exciting opportunities for Scrum Teams to find new and more effective ways of working. With the changes to the definition of the Sprint Backlog, teams may find Scrum more appropriate to processing simpler work items, or they may find a perfect application for new and emerging engineering practices.
In any case, this new way of seeing the Sprint Backlog affords opportunities for Scrum itself to flex and grow with the needs of teams and organizations.
|
Chickens and Pigs
The chicken and pig lore of Scrum is no longer a part of the Scrum Guide. Professional Scrum Trainer Steve Porter discusses the signifigance of what some may assume to be a relatively innocuous change:
As you're probably aware, Jeff Sutherland and Ken Schwaber recently published an update to The Scrum Guide, the definitive guide to Scrum. Many of the changes they made aimed to better define the rules of the game, and remove situational tactics. Some changes were large in scope and others less apparent.
One particular change was arguably small and cosmetic, but it really has significance in my opinion. So much so, that I offered to write this brief article to explain why the change was made and how you can interpret these changes as you go about implementing them in your projects.
Every Scrum practitioner has heard the fable of the chicken and the pigs. I won't recount it here, but it is an embedded part of Scrum lore. Ken Schwaber created the pigs and the chicken metaphor in the early days of Scrum and it has been used repeatedly to separate the people who are committed to the project from the people who are simply involved.
Over the years, the labels have generated their share of controversy. Some argue that the terms are harmful to the process because they are derogatory. Others say that the negative connotation conjures a power dynamic that drives negative behaviour. Either way, you won't find any references to animals, barnyard or otherwise, in the new Scrum Guide.
Why was it removed? Ken and Jeff felt it was better to discuss accountability directly in the Scrum Guide, as opposed to through metaphor. However, I think I can provide some additional insight. I was present at some of the discussions that led to the 2011 update and many people, including me, found that the labels were being used in a way that does not contribute positively to a team's ability to perform its core function.
The labels were being used to create barriers between the Scrum team and individuals in the organization who potentially could assist the team in meeting its goals. Jeff Sutherland has been quoted as saying that, "… others should come up with a euphemism that conveys the right balance between being ‘nice’ and communicating clearly that eavesdroppers must minimize their impact on the productivity of the team.”
As a consultant, I witness many key members of an organization pull themselves away from a Scrum team with comments such as, "I know I'm just a chicken, so I can't say anything.” In some cases these people were key project sponsors or critical system matter experts. These are individuals who, while possibly needing some education and guidance from a Scrum Master, can be critical to the success of a project. The better the level of engagement you get from all of your stakeholders, the better off your project will be. By calling someone a chicken, it doesn't exactly look like you're rolling out the red carpet.
Another consideration is that Scrum, as a framework for delivering products, has come a long way. It's now used in all manner of organizations, including large, significant corporate environments. I welcome this development because I think there is great potential to improve the working environments of development professionals in these organizations through the use of Scrum. If we want to be taken seriously in these types of organizations, we need to make sure that we can communicate effectively with the various stakeholders with whom we engage. I welcome the challenge of working with a corporate executive in a fortune 100 company to help him/her create products of the highest possible value. I don't want to start that relationship by referring to him/her as small-brained fowl and myself as the animal that took over George Orwell’s Animal Farm.
So, where does this change leave you? Fortunately, the updated Scrum guide still makes a distinction between members of the Scrum team and those individuals who are part of the process, but not responsible for delivering products. However, the language has been changed. We still have the Scrum Team, but now the guide makes reference to "the organization," "employees" and "stakeholders" rather than pigs and chickens.
The updated guide also makes it very clear that, "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” For all the Scrum Masters out there who have to deal with intrusively engaged stakeholders, print out the new guide, highlight the appropriate passage and make it available early and often.
|
Ordered Not Prioritized
"Prioritizing" has been removed in favor of "ordering" as the term for organizing the Product Backlog. Ken and Jeff asked Jim Coplien to elaborate on the reason for this change:
In the past, the Scrum Guide consistently used the word "priority" for the Product Backlog or noted that the Product Backlog was “prioritized.” While the Product Backlog must be ordered, ordering by priority is only one many techniques — and rarely the best one at that. The new Scrum Guide instead uses the term ordered for the Product Backlog. This reflects a long-held understanding by many leaders in the Scrum community. Let’s clarify the reason for the change.
To prioritize a list means to order its items by their importance relative to each other. Priorities drive pair-wise comparisons (by English language definition) of items on the list. Think of using bubble sort to prioritize the Product Backlog: compare the top two items and interchange them if they’re in the wrong order, and then move on to the next pair, and keep cycling through the list until everything is in its place. Prioritization and sorting go hand in hand. All the comparisons are local. This process is analogous to local optimization.
More broadly, the Scrum Team and the Product Owner in particular need to consider the entire backlog when ordering PBIs, to optimize value or ROI. Most people commonly think of ROI as the priority; however, you need to think of ROI as a long-term result of the total backlog ordering rather than just the sum of the ROI of individual items. This is true in part because the ROI of an individual item depends on its position in the backlog. Let’s say that you have a PBI to put dancing Santa Clause figures on the welcome screen to a web site. That item will lead to some ROI in late November and during December, but much less ROI in July or even in the ensuing January. Moving the item on the backlog changes its ROI (or, more generally, any such per-item ordering criterion), because re-positioning it changes its release date. Even the shifts caused by bubble sort would cause the PBIs’ “priority” to change as a side effect of prioritization itself.
The Product Backlog indeed must be ordered: its ordering determines PBIs’ order of delivery. The Development Team can discuss PBI ordering with the Product Owner but, in the end, the Development Team must take PBIs in Product Backlog order. However, the Product Backlog is not guaranteed to represent an ordering of PBIs by either value or priority. You can’t just assign priorities to PBIs — whether they come from ROI or importance to the business or anywhere else — and then prioritize the backlog on the basis of those relative values. You must consider the entire backlog of PBIs together.
Let’s say you’re building a house in the tropics, with your main reason being to keep off the afternoon rain that comes every day. You envision a house with walls, windows, and doors, but it’s really the roof that you’re after. You build a Product Backlog for your house. Would you put the roof first? That would be a prioritized backlog. What you do is to order the backlog to yield the highest long-term ROI. (The same principles also apply to short-term ROI, for what it’s worth.) To do so takes deep knowledge of the business, knowledge of business, market, and engineering dependencies between PBIs, knowledge of evolving market windows and market conditions, the state of the supply chain, and a host of other details that are much more complex than anything like bubble sort can accommodate.
To use the term “ordering” instead of “prioritization” also makes it clear that the Product Owner must make decisions. He or she cannot just say “These five items are all priority 1; these three items are priority 2” and so forth. The Product Owner must deliver a totally ordered Product Backlog.
Of course, you can use prioritization as the ordering technique because prioritization is but one form of ordering. Ordering PBIs by their "priority" leads to suboptimal market value and reduced ROI. Jeff Sutherland has often said that you can double ROI by reordering the backlog. Usually, the best orderings are not priority orderings. There are exceptions and some special occasions when you order the backlog by ROI priority, particularly when implementing advanced fixed-cost contracts for individual customers: see CHANGE FOR FREE and MONEY FOR NOTHING. However, those are highly contextualized techniques for single customers with fixed-cost (and sometimes fixed-scope) contracts. They do not apply universally, and the Scrum Guide does not and should not stipulate their use — nor the prioritization necessary to support them. More generally, you will use a non-prioritized ordering. Inspect and adapt.