To set the stage for this chapter, try answering each of the following statements with Agree or Disagree. Answers appear at the end of the chapter.
Scrum is an agile process.
Scrum Teams do very little planning.
If a Scrum Team changes the Scrum framework, they are no longer doing Scrum.
If a Scrum Team adds to the Scrum framework, they are no longer doing Scrum.
Every Scrum event is time-boxed.
The development process is owned by the Development Team. The Product Owner does not have a say.
From the Scrum Guide
Scrum is a framework for developing, delivering, and sustaining complex products.1
Scrum is a framework (see Figure 6-1). But what does that mean? Why not call it a process?
Scrum carefully avoids referring to itself as a process. Why?
In a court of law, you would likely lose the argument that Scrum isn’t a process. It has ordered events, roles, and artifacts. Sounds like a process.
The key element here is ownership. Who should truly “own” the process? Management? Your organization’s Project Management Office (PMO)? Some book or guide? Schwaber and Sutherland?
Of course not. If you have been following along so far, the answer here should be obvious. The Scrum Team needs to own the process. Each team, each product, each company is different, and each process must emerge to support their unique needs. However, it would be helpful if teams could start with something to build upon, a minimal set of rules: a framework.
A metaphor that works here is renting versus owning a house. If you rent a house and something goes wrong, what do you do? You pick up the phone and complain to the landlord. Then you complain about how things are always breaking and you deserve better support from the landlord. You feel victimized.
However, if you own a house and something goes wrong, what do you do? Nowhere to turn, right? You need to suck it up and deal with the problem yourself. You make decisions based on return (value) and investment (cost, time). Sometimes you fix it on your own, sometimes you call an expert, and in some cases, you just live with it. In the end, it’s all about finding a workable solution for which you are accountable.
The same happens with processes. If the process is defined and installed from outside of the team and “forced” upon them, when something goes wrong they call their management/PMO. They assign blame to the process and complain about it over lunch with their colleagues and online with angry posts. It becomes all about finger pointing.
Now when a team sees Scrum as a starting point, a true framework with built-in opportunities to change and improve, they take ownership. They have nowhere to point to but themselves if (when) things do not work out. This is the essential ingredient for accountability and self-organization.
As the previous chapter explains, complexity requires emergent practices. Team ownership over a flexible (empirical) process is key to this.
If organizations are not careful, Scrum can also be viewed as a rented process.
I have worked with companies that started with a pilot team to test Scrum. Since Scrum is just a framework, described in a 17-page document,2 there is no step-by-step installation guide. So the Scrum Team needs to figure it out for themselves. They read books and blogs, they experiment, they fail, and eventually they land on something that works for them—a true process, owned by the Scrum Team.
Seeing the ultimate success of the pilot, management then asks the team to list out everything they did so that they can have all other teams do the same. What title did your Scrum Master have? What about the Product Owner? What tools did you use? How long were your Sprints? What time of day did you hold your Daily Scrums? What color stickies did you use?
Unfortunately, by having the subsequent teams copy the pilot team’s Scrum-based process instead of the Scrum framework, we are back to renting a process. The subsequent teams will not have the same sense of ownership and will fall back into blaming the Scrum process, the managers, and maybe even the pilot team.
You can see this reflected within almost any anti-Scrum rhetoric online.
Do a little digging and you will see the complaints are not about framework elements but instead about practices that were instituted on top of Scrum (often sizing mechanics, requirements capture, Sprint commitment, task management, etc.) by people outside the team (managers, PMOs, agile “coaches,” tools, etc.).
With help from the Scrum Guide itself, let’s look at the core elements of the Scrum framework.
From the Scrum Guide
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.3
Figure 6-2 symbolizes the three pillars of Scrum. Without all three in place, the whole construct collapses.
From the Scrum Guide
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
A common language referring to the process must be shared by all participants; and,
Those performing the work and those inspecting the resulting increment must share a common definition of “Done.”4
Imagine an organization that has all the data (inspection) and the ability to change (adaptation), but no transparency. The data may not reflect the true reality and may not be visible to the right people. Therefore, what they inspect will be incorrect and how they adapt will be wasteful. Having a culture that promotes openness and communication is essential for any empirical process to work effectively.
A lack of transparency is like putting a wet washcloth over a thermostat. The thermostat will inspect inaccurate data and adapt in the wrong way.
From the Scrum Guide
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.5
Imagine an organization that has nothing to hide and has solid communication (transparency) as well as the ability to change (adaptation). However, they have not taken the time to gather and analyze the data in any consistent way. You will end up with people feeling like they should adapt a certain way; but with no hard evidence to back it up, real change becomes more difficult. Having consistent and short feedback loops as well as clear information radiators is essential for any empirical process to work effectively.
From the Scrum Guide
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal events for inspection and adaptation . . . :
Imagine an organization that has all the accurate data (transparency and inspection) necessary to change in a meaningful way. However, nobody is empowered or willing to do anything about it (adaptation). The ability to execute is essential for any empirical process to work effectively.
Vision without execution is hallucination.
The three defined Scrum roles are Product Owner, Development Team, and Scrum Master. While there are many other roles within organizations that are vital to the success of the product, these three must be in place for the Scrum framework.
From the Scrum Guide
The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.7
A single person who truly owns the product and has the last say is crucial for product success.
What good is it to have the best Development Team if the wrong product is being built? The Product Owner is the keystone on which the right product—the overall product quality—depends.
Figure 6-3 shows how Scrum uses a built-in flow of service. Ultimately, the Development Team is there to serve the Product Owner, and the Scrum Master serves the Development Team. You could also say that the Product Owner serves the customer and other stakeholders.
Building on top of what is covered in “The Product Owner” section in the first chapter, let’s look at how the Product Owner works on a day-to-day basis.
I often draw the Product Owner with a crown (see Figure 6-4). As queen or king, you have the right to make all decisions regarding your kingdom. As long as you do a good job, your stakeholders will respect and even love you. If things go south for too long, you might face a revolution with dire consequences.
As the Product Owner, you have the absolute right to make all product decisions. This is in contrast to a traditional project manager who is responsible for making sure that the project stays within scope, schedule, and budget. Whether the product is the right product and whether the product creates value for the users and customers are likely not a project manager’s top concerns. As a Product Owner, this is your purpose. You are the value maximizer for the product.
As the value maximizer, it is mandatory to understand the domain of the product and to identify and work closely with all stakeholders such as customers, users, and executives.
I was once coaching and overseeing a large program to replace the existing scanner at Swiss Postal Services. Since more than 20,000 personnel used the device, we invited postal workers on a regular basis. They took part in the Product Backlog refinement when challenging processes were being refined, in user-interface workshops, and every two weeks for the Sprint Review. Our goal was not to just replace the old system, but to create value to thousands of people as they deliver millions of letters and boxes every day.
It should be obvious that being appointed as Product Owner for a product in a domain you do not actually understand is a questionable decision. Most likely this Product Owner will become a proxy (as described in Chapter 1), which will result in delays and information loss every single day. A good Product Owner is a domain expert who knows the business from many angles. This allows the Product Owner to quickly navigate and adjust as new information emerges in synchronization with the stakeholders. A Product Owner who is a proxy only collects stakeholder requests and orders them in a way that pleases their loudest stakeholders (squeaky wheels). A Product Owner who steps up and owns the product plays an important role toward creating an agile business.
Realistically, demanding a Product Owner to know everything about the domain is an almost impossible request. While still maintaining the vision and ownership, an effective Product Owner should be able to leverage other Subject Matter Experts (SMEs) to help guide the product. The Product Owner could even create direct communication lines between Development Teams and the stakeholders. This is even more true in a scaled environment where the Product Owner’s capacity is strained.
I have had a Product Owner who brought an SME from the legal department to Sprint Planning and announced that she honestly did not know much about the legal details for the features we were focusing on that Sprint. She made it clear that we could go directly to the SME for the specifics and that she trusted any decisions made by him. It was obvious that this did not relieve the Product Owner of accountability. She was doing what was right to create an excellent product Increment that Sprint.
From the Scrum Guide
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.8
Apart from working closely with all stakeholders, a good Product Owner also works closely with the Development Team. Actually, the Product Owner should include the Development Team in quite a bit of tactical work on the Product Backlog, refinement, acceptance criteria, and other areas. Figure 6-5 shows that while some areas are squarely the responsibility of either the Product Owner or the Development Team, the Scrum framework also builds in plenty of opportunities for both parties to collaborate and share responsibility.
What you really need to avoid is a requirements hand-off from the Product Owner to the Development Team. The more closely the Development Team is engaged with the features and their refinement, the more the Product Backlog items become theirs. This leads to more ownership, stronger engagement, and pride, which are key steps toward achieving excellence.
On a day-to-day basis, this means that you, as Product Owner, spend less time specifying requirements and more time educating the Development Team about the value of the requirements. Give them the support they need and then trust them to come up with a solution.
When refining the Product Backlog for upcoming Sprints, do not just hand over and explain. Use the refinement to provide understanding, answer initial questions, and then let the Development Team do their work. During the Sprint, support the Development Team wherever needed and provide feedback on Product Backlog items. The benefit here is not only that the Development Team gains better understanding and ownership of the Product Backlog, but this approach also frees you up to do the more strategic Product Owner work, like analyzing the market, observing the competition, talking to sales and marketing, aligning with other Product Owners, talking to stakeholders, and so on.
You will want to keep an eye on overall progress of the Product Backlog as you still have overall accountability. However, the plan for the Sprint belongs to the Development Team, so dictating what they work on and when is not your call.
Remember, the Development Team’s accountability is to produce a “Done” working Increment of the product every single Sprint. Accomplishing this requires the Development Team to have all the skills necessary to reach “no work remaining,” as in “yes, we can ship.”
What’s in the Development Team can be in the product; what is not cannot.
Imagine you and your cooking friends are asked to cater a big event. All of you have spent quite some time in the kitchen cooking together. You know each other, you have established a routine for communication and moving around so as not to impede others. This, in combination with a stocked pantry, sets you up to amaze some palates.
But let’s assume not everything is perfect. Maybe two of your friends cannot make it, or the pantry is missing some key ingredients, or your team really does not have the skills needed to pull off the requested menu. You could certainly improvise, but that choice carries risks. The likelihood of having a successful outcome is greatly reduced.
Taking this analogy into the world of a software product development, it becomes obvious that what is in the Development Team can be in the product, but what is not most likely cannot. You can improvise, depend on external people, or come up with other creative workarounds. But in doing so you create significant risk for the feature quality, the technical quality, and progress.
As Product Owner, you never start with a perfect Development Team. It emerges over time. So give them the time, focus, and resources they need to become a professional team. Making use of Sprint Retrospectives and measuring key indicators like on-product index, innovation rate, and employee satisfaction (as described in Chapter 3) can help.
According to Sandy Mamoli and David Mole, 60 percent of success depends on the people doing the work.9 Companies that realize this do not fund projects. They fund teams that build and maintain a product, as shown in Figure 6-6.
From the Scrum Guide
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
Finding techniques for effective Product Backlog management;
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
Understanding product planning in an empirical environment;
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
Understanding and practicing agility; and,
Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including:
Coaching the Development Team in self-organization and cross-functionality;
Helping the Development Team to create high-value products;
Removing impediments to the Development Team’s progress;
Facilitating Scrum events as requested or needed; and,
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
Leading and coaching the organization in its Scrum adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact Scrum and empirical product development;
Causing change that increases the productivity of the Scrum Team; and,
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.10
The Scrum Master is there to help you, the Product Owner, to maximize value. This is mostly done with the Scrum Master coaching the Development Team. While doing this, the Scrum Master brings focus to all kinds of impediments that have an impact on the Development Team. As the Product Owner, you need information about the product quality, the progress, the status of the risks, and more, depending on the product you develop. These are all things you can and should expect from your Scrum Master and Development Team as this information is vital to making sound decisions. Ensuring that the proper mechanisms are in place for transparency, inspection, and adaptation is a big part of the Scrum Master role and allows the Product Owner and Development Team to do their jobs more effectively.
Should the Scrum Master be knowledgeable about the business domain? There clearly is no harm; however, it is not a necessity. This is the beauty of the separation of roles within Scrum. The product quality, building the right product with value for the users, is with the Product Owner. The technical quality of the product lies with the Development Team. The Scrum Master facilitates all these responsibilities. In fact, a lack of knowledge of the domain could even be considered a benefit, freeing the Scrum Master to focus on facilitation, coaching, team dynamics, and to ensure that a process, based on the Scrum Framework, is emerging.
As consultants, we spend a lot of time facilitating Scrum Teams from all sorts of industries. In many cases, they seem to be speaking a completely different language. However, as facilitators, our focus is not on the solution but on the process. Not getting too entangled in their domain actually makes us more effective at reading the room, keeping things on track, and looking for process gaps.
Other roles relevant to Scrum include the Scrum Team and stakeholders.
From the Scrum Guide
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.11
Too often, the terms “Development Team” and “Scrum Team” are used interchangeably. They are not the same: The Development Team is part of the Scrum Team. Often this subtle difference can have a big impact when generically talking about the “Team” and understanding where the responsibilities belong.
Although not an official Scrum role, stakeholders are key to the success of any Scrum development effort. These are the users, customers, investors, executives, compliance officers, and anybody whose lives are affected by the product under development.
As Product Owner, it is your responsibility to identify the stakeholders who have a say in the direction of the Product and to ensure they are included.
Scrum provides many built-in opportunities to engage with your stakeholders. The obvious one is the Sprint Review, where stakeholders can provide feedback on the Increment that subsequently affects the Product Backlog.
However, including stakeholders in Sprint Planning and Product Backlog refinement can also be beneficial and should be done at the discretion of the Product Owner.
A good brainstorming activity to identify your stakeholders is to work through a mind map such as the one in Figure 6-7.
For each category shown in Figure 6-7 (consider adding new categories that are specific to your product), name organizational roles and even the people in those roles. Doing so will likely result in an extensive list of stakeholders, each with unique needs and expectations about the direction of the product and how they would like to be included.
Another helpful technique is to place your stakeholders on an “influence 232” such as the one in Figure 6-8.12
This tool gives you a better idea of how to involve your stakeholders. Consider involving your interested parties more often, even during the Sprint where they can help with details. You may be able to accommodate the less interested parties in other ways that are less time consuming but still keeps them happy. Active stakeholder management builds trust, especially once they see the impact they can have on the product. It also shifts accountability to stakeholders: The more they are involved during development, the less they can complain once the product is released.
For stakeholders who have high interest yet low power (bottom right of Figure 6-8), consider putting them to work. As Product Owner, there is a lot to do. Maybe these stakeholders are willing to help with the more tactical items while you focus more on strategy.
There are just three mandatory artifacts in Scrum: the Product Backlog, the Sprint Backlog, and the Increment.
The three artifacts are linked: The Increment is generated from the Sprint Backlog, and the Sprint Backlog is generated from the Product Backlog. The Product Backlog is then refined based on feedback from the Increment (see Figure 6-9).
From the Scrum Guide
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “done.”
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed. . . .
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.13
In the next chapter, we will get into more details about how to create and maintain a Product Backlog.
As Product Owner, consider the Product Backlog as your current path. This path represents a snapshot of your best understanding on how to get to your final destination. No matter how good your velocity is, the wrong path will not get you to your goal; you will simply end up at the wrong destination faster.
A well-refined, ordered, and estimated Product Backlog provides you with direction and with all the information necessary for reporting and planning. However, for this to work, you need to make sure that the Product Backlog is your only—as in one—source of work for the Development Team. Assume that you have a Product Backlog for the features, a bug backlog for the issues, a technical backlog for infrastructure and architectural work, and you have unplanned work injected during the Sprint. In that suboptimal (yet common) situation, there is no true transparency regarding your direction. It is hard or even impossible to measure your bearings.
At the risk of repeating ourselves, the following rule always applies:
One Product → One Product Owner → One Product Backlog
And this Product Backlog contains all the work for the Development Team.
From the Scrum Guide
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 into a “Done” Increment.
The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.14
The Sprint Backlog belongs to the Development Team. It is their plan on how best to meet the Sprint Goal. As the Product Owner, you can determine the most important Product Backlog items for the Development Team to consider in their Sprint plan, but you cannot dictate how much they take on or how they will break down their work.
This is an essential part in building a mutually respectful relationship between these two roles. A Development Team that truly owns the plan for the Sprint will demonstrate much more accountability and ownership over the work of the Sprint.
Together with the Development Team, you define the Sprint Goal in Sprint Planning and then trust them to create the Sprint Backlog and maintain it throughout the Sprint.
Sprint Goal → Sprint Backlog = Forecasted Product Backlog items (what) + Plan to deliver them (how)
If Scrum was reduced to one and only one sentence, it would be to have “releasable working product every 30 days or less.” That releasable working product is the Increment.
From the Scrum Guide
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The Increment must be in useable condition regardless of whether the Product Owner decides to actually release it.15
As Product Owner, a valuable Increment at the end of each Sprint is the goal you share with the Development Team. Although you do not have much say in how the Development Team plans their work in a Sprint, you should still expect a working “Done” Increment each time. Product Owners do have the right to challenge their Development Teams to create an Increment of value and not settle for just plans, designs, mock-ups, and similar outputs.
If the Product Backlog represents the direction of your current path, then the Increment is your GPS device that determines your current position. The Increment provides transparency for you and your stakeholders. In that sense, it is the most important element in the Sprint Review and fuels the most important feedback loop in an empirical process control. A working Increment allows you to inspect and adapt together and to determine the next steps, thereby updating your path—the Product Backlog.
For this to work, your Increment needs to be truly “Done.” How could you find your position with an inaccurate GPS reading? You can’t; and this lack of transparency is detrimental or even catastrophic. In the long run, you will lose your way.
Although not official Scrum artifacts, other generally accepted Scrum practices that should be strongly considered are burn-down/burn-up charts and a definition of “Done”.
From the Scrum Guide
When a Product Backlog item or an Increment is described as “Done,” everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done.”
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.16
If the Product Backlog is your path and the Increment is your compass, then “Done” is the magnetic field that points the needle. No needle, no location, no path-calibration.
At least once a Sprint, your Increment (your product) must be “Done”: “Done” as in no work remaining, as in it can be released. Whatever “Done” means in your context is something you as the Product Owner (representing the stakeholders) and the Development Team must work out. All needs regarding “Done” have to be addressed accordingly. “Done” reaches from the end user all the way to operations.
Not “Done” → no Increment → nothing to show in the Sprint Review
If you ignore “Done,” at best, you are just making progress. The question is toward what?
Read more about “Done” in the next chapter on Product Backlog management.
Continuing with the path metaphor, during your journey in creating an awesome product, it is helpful to have a map with you. Two popular tools in the Scrum community are burn-down and burn-up charts. They can bring visibility to your journey’s progress so that you can better inspect and adapt your path.
The Sprint burn-down provides transparency—location—for the Development Team. It allows them to inspect and adapt their plan during the Sprint and to gauge their progress toward the Sprint Goal.
Figure 6-10 shows a Sprint burn-down chart. The dashed line (with x’s) represents the hours remaining from the Sprint Backlog. The solid line represents the story points remaining from the forecast.
Although the Sprint burn-down chart is not meant for you, the Product Owner, you should be able to see it to get a gauge on how the Sprint is going. But it is not your responsibility to act on it.
A Product Owner and their stakeholders are likely more interested in progress across Sprints. For that, you have release burn-downs or burn-ups.
From the Scrum Guide
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.17
The important words here are “work remaining.” How much the team has worked is irrelevant; you should care only about how much work is remaining so that you can plan better. Your Development Team can work for 10 hours and discover 20 extra hours of work, or complete three Product Backlog items and discover five more, increasing the amount of work remaining. Regardless of what they did in the past, it does not change the fact that this new work still needs to get done. So you adapt the plan going forward.
Burn-down charts are a great way to visualize work remaining. But feel free to use other charts as long as they provide visibility to the work remaining.
Building release burn-downs/burn-ups (see Figures 6-11 and 6-12) as a way to represent release plans will be covered in more detail in Chapter 8.
There are five mandatory events in Scrum: the Sprint, the Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
In Scrum, each time-boxed event is designed to provide a specific inspect and adapt opportunity. In other words, there is always tangible input and always an explicit output for each event.
The Sprint is the container for all the other Scrum events. It is like a mini-project after which you have a working product—the Increment. The worst-case scenario is that you waste one Sprint. The shorter the Sprint, the smaller the risk.
From the Scrum Guide
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done,” useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.18
As Product Owner, the Sprint is the feedback loop with which you can inspect and adapt the direction of your product. Each Sprint must end with a working Increment that you can test with a sampling of stakeholders or, better yet, against the marketplace. Based on that feedback, you can have the Development Team work on anything you deem most valuable in the next Sprints. This provides you with the utmost flexibility.
Keep in mind, although you have the flexibility to change direction from Sprint to Sprint, you must avoid changing the scope of a current Sprint as much as possible. If the need for changing the Sprint scope is a recurring problem, consider shorter Sprints.
A Sprint provides stability in a world of unpredictability. The Scrum Team makes hard choices about requirements, infrastructure, and people. It tries to stick with those choices for at least one Sprint and then inspects and adapts for the next Sprint. Sprints that are too long could set you too far off course, increasing the cost of getting back on track.
The length of the Sprint should be determined by how much of this stable work a Scrum Team can (should) take on. This is the Product Owner’s planning horizon.
Realistically, there will be exceptions to keeping a Sprint stable. Consider the following scenario:
As Product Owner, an exciting new feature comes across your desk. Arguably, it is more valuable than any of the Product Backlog items that the Development Team is working on in the current Sprint. What do you do? You have three options.
1. The best response is to place the new feature on the top of your Product Backlog and not disrupt the current Sprint. If what is already in the Sprint still has value, then let the Development Team finish. Too often, they are interrupted with new work and do not get to finish what they have started. There are few things more inefficient than constant starting and stopping. Help your team to “stop starting and start finishing.”
When I was a programmer on a Development Team, I used to get constant interruptions by managers and business people about new requests. My first question was always, “Is this more important than this thing I am currently working on?” The honest answer was often “Yes!” But this often meant that my work was consistently getting trumped by something else, which resulted in plenty of wasted effort and stress with no value to show for it. Today, I spend a lot of time coaching Product Owners and always make a point of telling them about my experience as a Development Team member so that they realize the overall impact of disrupting the Sprint.
I teach my Development Team to answer the following way every time someone outside of the Scrum Team approaches them with a small, but very important favor: “It sure is important, but this is not my decision to make. Please go and talk to my Product Owner.” If the Product Owner does not handle the situation correctly, then it is up to the Scrum Master to protect the Development Team.
2. When the new feature request nullifies some of the Product Backlog items being worked on in the current Sprint, then the situation is different. There is no point in working on items that have no value. The obvious thing to do here is to go ahead and adjust the scope of the Sprint, without endangering the Sprint Goal. This will likely mean swapping out Product Backlog items.
3. The third option is that if you determine that the new feature replaces the need for everything in the current Sprint and voids the Sprint Goal, then this is where the Product Owner can consider canceling the entire Sprint. Since there is no point to continuing, stop the Sprint and immediately start planning a new Sprint. Given all the previous options, this should certainly not be a common activity.
From the Scrum Guide
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.19
From the Scrum Guide
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
Sprint Planning answers the following:
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?20
Topic One: What Can Be Done This Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Topic Two: How Will the Chosen Work Get Done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.21
Figure 6-13 outlines the flow of Sprint Planning.
In Sprint Planning, the Scrum Team comes up with a Sprint Goal, the supporting items out of the Product Backlog: the forecast (1. What), and the resulting work to be done for each of those items (2. How). All of this together is referred to as the Sprint Backlog: the plan for the current Sprint.
Let’s look at two possible scenarios of Sprint Planning.
You, as Product Owner, have created all the Product Backlog items for this Sprint. You spent a fair amount of time writing the Product Backlog items as user stories, coming up with acceptance criteria and even a few UI sketches. At Sprint Planning, the Development Team is pointed to this Product Backlog and asked to plan the Sprint.
Before the upcoming Sprint, you as Product Owner—potentially during prior Product Backlog refinement—explain to the Development Team your next highest level goals. When you take a more narrative approach, the Development Teams gets a clearer understanding of what needs to be done. They get a chance to ask questions and solidify their understanding. Once they understand, they can help to create or refine the Product Backlog items (even on their own) until they feel the items are ready for the next Sprint. During the next Sprint Planning, you go through the top of the Product Backlog together and make any last-minute changes and answer any other questions.
Which scenario has a higher likelihood of being successful?
The first scenario is a handoff, with all its associated risks.
The good news is that you are only handing over a smaller portion of the product. But it is still a handoff. And like any handoff, it can cause ambiguity as the written word is never the best way to communicate complexity.
I once heard this great example: A mother leaves a note for her son: “We are running low on milk, could you go to the store around the corner and buy a gallon of milk and if they have eggs, get six.” The son runs off to the store and when he returns, he puts six gallons of milk on the table and tells his mom, “Yes, they had eggs.”
Agile blends the business with engineering, which avoids the classic handoff problem in a phased linear development approach. As the first scenario above showed, even Scrum is not immune to this handoff problem. It is likely that some items turn out slightly different than anticipated, and often the answer from the Development Team is, “OK, but we did what was specified here, it is not our fault!” Back to finger pointing, blaming, and requesting more detailed requirements (CYA).22
The second scenario engages the Development Team from the beginning. They understand the purpose of why they are doing this. They take ownership of the functionality; it becomes theirs. If something is yours, you watch out for it, you take care of it, you want to make it a success.
As described previously, you as the Product Owner are motivating the Development Team by leveraging what is described in Dan Pink’s book Drive:
Autonomy → Mastery → Purpose
Each Sprint Planning event must capture a shared Sprint Goal. A good Product Owner should enter Sprint Planning with a goal in mind. However, this should be open for negotiation with the Development Team based on their input, ability, and capacity. The resulting Sprint Goal is owned by the whole Scrum Team.
Your Sprint Goal should be considered as the elevator pitch for the Sprint. Imagine a stakeholder passes you in the hallway one day and says, “Looking forward to the Sprint Review next week! What will I get to see?” How will you respond? Would you rattle off the nine Product Backlog items being worked on? Or would you give her a more concise summary of the most important element? If you find it hard to give an overall summary, it is likely a sign that there isn’t much cohesion in your Sprint. In other words, the harder it is to come up with a good concise Sprint Goal, the more you probably need one.
This does not mean that you cannot have Product Backlog items in a Sprint that are unrelated to the Sprint Goal. Certainly, they could also work on an extra feature, report, or bug that a stakeholder has asked for. However, they should be in the minority and would likely be the items dropped from the Sprint when the Sprint Goal is at risk of not being met.
Think about the Sprint Goals as a linked list of objectives that are guiding you toward your overall product vision one step at time. Having homed in on your vision, you identify upcoming goals toward the grand goal (see Figure 6-14). The Sprint goals are not afterthoughts, but honing beacons. Figure 6-15 shows some examples of Sprint Goals.
I have seen great results using what I call the “Sprint Goal Driven Development” approach. Instead of “feeding” the Development Team with requirements for an upcoming Sprint, provide them with a Sprint Goal ahead of time and let them drive out the details, let them create the Product Backlog items, let them take ownership. You as Product Owner provide feedback and guidance during the refinement.
Your Sprint Goal should never be a comma list of user stories (Product Backlog items) to be completed by the end of the Sprint.
I once saw the following Sprint Goal: “Our Sprint Goal is to reach the Sprint Goal.” Please put in a better effort than this.
From the Scrum Guide
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance
by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.23
The Daily Scrum is about the Development Team inspecting and adapting their Sprint Plan on a daily basis. As the Sprint Plan is owned by the Development Team, the Daily Scrum is not for you, the Product Owner. Therefore, this is not your opportunity to ask for a status update or to inform the Development Team on recent events. You are welcome to attend to show your engagement and to make yourself available afterward, but you do not participate during the Daily Scrum.
Having regular communication with the Development Team is still a great idea. Just do not hijack the Daily Scrum for this. Set something else up that works best for your particular situation.
I worked with a team that was complaining about the availability of their Product Owner, Irene. Irene was a VP who was committed to the product, but if we did not reserve her time weeks ahead, others filled up her calendar. Not knowing exactly how much time we would need from her each day made it hard to schedule anything. When this was brought up in a Sprint Retrospective, a team member came up with a great solution. Like in college, what if we scheduled “professor office hours” with the Product Owner? Irene could block one hour each day during which we could ask her questions and show her completed work. She responded with great enthusiasm to the idea and happily used any leftover minutes to catch up on e-mail and other tasks. This is a great example of process ownership and adaptation.
I once worked on internal software for researchers at a pharmaceutical company. Very interesting product in a very complex domain. Our Product Owner set aside two hours every week to provide us with a 101 into pharmaceutical research.
From the Scrum Guide
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.
The Sprint Review includes the following elements:
Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.24
In many ways, the Sprint Review is the Product Owner’s most valuable event. This is your opportunity to recalibrate your compass and adjust your path. This is not your opportunity to provide feedback and accept or reject the work done in the Sprint (although many suboptimal Sprint Reviews violate this guideline). You should be doing that during a Sprint and not even demonstrating any of the work you did not approve. The core objective of the Sprint Review is to get feedback from your stakeholders and, based on that feedback, update the Product Backlog (your future path).
I have a simple rule for the Sprint Review: No PowerPoint! So, what to show? How about real, working “Done” software?
The stance you should take in the Sprint Review is more like a representative of the Scrum Team and host. You should kick it off by revisiting the product vision with everyone and sharing the Sprint Goal. Then let the audience know how the Sprint went with regards to the Sprint Goal. A common and useful next step is to invite members from the Development Team to demonstrate the “Done” work. This is a great opportunity to give stakeholders facetime with the Development Team, which builds trust, motivation, and ownership. While the Increment is being inspected, encourage feedback from stakeholders and make sure to capture it—hopefully directly in the Product Backlog. A good way to conclude the Sprint Review is to review the release plan with everyone. Given that a Sprint was just completed, this will provide new data from which to inspect and adapt the future path of the Product Backlog. Figure 6-16 shows an example agenda for a Sprint Review.
From the Scrum Guide
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.
The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done,” if appropriate and not in conflict with product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.26
Notice that the Scrum Guide identifies the Sprint Retrospective as an opportunity for the “Scrum Team” to inspect and adapt themselves and their processes. That means you, the Product Owner, are also expected to participate and have input to the development process. Product Owners are too often left out of these crucial meetings, likely because they are not always seen as part of the team. If this sounds familiar, then you should set out to rectify it. Show that you are a team player by participating like an equal and being honest, open, and receptive.
Product Owners often find themselves in a position of authority. This could shut a Development Team down during a Retrospective. In other words, they may not be as outspoken with you around, which could reduce transparency. As Product Owner, make it your mission to bridge that gap. Participate in team-building activities, invite team members to stop by your office, ask them to text or call you about anything. Be a team player.
Suboptimal Scrum implementations drop the Sprint Retrospective more often than any other Scrum event. However, I often refer to the Sprint Retrospective as the most important event. Imagine a team that had no process at all except for a weekly meeting to discuss how the week went and what they will do the following week to improve. Done correctly, the result of this will ultimately be an ideal set of practices, customized for that team. In other words, a process—fully owned by the team. So, the idea of dropping this event is somewhat absurd.
Although not an official time-boxed event, another important activity in Scrum is Product Backlog refinement.
After “Done,” “Ready” is the next best thing. If you do not know what “Done” means, you will have a hard time finishing anything. If you are not “Ready,” you will have a hard time starting anything. Refinement is about getting your Product Backlog “Ready” for upcoming Sprints. Refinement prepares the starting block for the Sprint, while “Done” sets the finish line.
In 2013, the Scrum Guide renamed Product Backlog grooming to Product Backlog refinement. In certain parts of the world, the word “grooming” has a negative connotation.
Figure 6-17 is taken from “The New New Product Development Game,” a popular Harvard Business Review article from 1986 by Hirotaka Takeuchi and Ikujiro Nonaka.27
“The New New Product Development Game” is the paper that inspired Ken Schwaber and Jeff Sutherland to create Scrum. Takeuchi and Nonaka referred to this approach for developing new products as a “Rugby approach,” which is constantly “moving the Scrum down the field.”
In Figure 6-17, Type B describes how the phases overlap. If you replace classical project management phases with Scrum Sprints, the figure describes refinement. Type B shows refinement for one Sprint ahead.
The overlap from Sprint 1 to Sprint 2 and so on is the time in the current Sprint you invest to make the subsequent Sprint “Ready.”
From the Scrum Guide
The Scrum Guide describes it in the following way:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.28
What about Type C? Assume you have some future Product Backlog items that need more forethought before they are ready. Or maybe you need deeper User Experience design that could take some time before it is ready to be consumed by a Sprint. In these cases, you must look further ahead than just one Sprint. Type C shows refinement for multiple Sprints ahead.
I like to do one refinement per Sprint week. If you have a Sprint of two weeks, you would have two refinements. As scheduled time, I start with two hours at the end of the workday, usually from 3:00 p.m. to 5 p.m. That is 5 percent of the described 10 percent. Then I inspect and adapt if needed. Sometimes an ad hoc additional refinement is all that is needed, sometimes I extend the refinements or add another one. I’ve realized the required time for refinement does not jump a lot, but might change depending where you are within your release, especially if you have major releases.
Done right, refinement provides you with a nice rolling Product Backlog (see Figure 6-18).
Velocity is the Development Team’s capability to turn “Ready” Product Backlog into a “Done” product Increment and simultaneously refine the upcoming Product Backlog to be “Ready” for the subsequent Sprint (see Figure 6-19).
Incremental development is like playing with Legos. You build your product one brick at a time (see Figure 6-20). This approach makes a lot of sense if you know everything upfront—like all the APIs, each step of the flow, the screens, and so on. This is attainable when you are in a predictable and defined domain with a clear correlation between cause and effect. Since software product development resides in the complex domain, it usually doesn’t work out exactly as planned.
Often an Increment is understood as just the addition to the existing product.
Merriam Webster’s defines “increment” as “the action or process of increasing especially in quantity or value : enlargement.” The word’s origin is “from Latin, incrementum, from the stem of increscere ‘grow.’”29
The Increment is the whole growing product, not just that little bit that was added since the last Sprint. The Scrum Guide also tells us that the Increment needs to be “Done” with no work remaining: that is, potentially releasable. That also means that the former Increment still needs to be “Done” even though it might have been changed in the current Sprint. Maybe the Development Team had to extend an API with an additional field, to swap a library with a thread-safe one, to change some aspects of the architecture to accommodate the new features. Those changes are not a bad thing or a sign of being a bad engineer, but rather acknowledge the emergent complex nature of product development.
In the agile community, it is understood that quality is not something you can test into the product after you have completed implementation; it must be built into the product from day one. This raises a question: How can you ensure that existing quality is not disappearing? This is one of the fundamental challenges in iterative and incremental development.
It boils down to good engineering practices and a sound setup of continuous integration/delivery with strong test automation.
This gives you a product that is capable of self-testing, providing you with an “I am OK and fully functional” feedback after every single build. That way, the Increment can grow (see Figure 6-21) and increase value without degrading over time.
I once worked with a team that developed a new service for a telecommunication company. I was fortunate that the developers on the Development Team were top notch and highly motivated. After the first major release, they had more than 10,000 unit tests and well above 600 integration tests. Their test coverage was around 95 percent. This coverage helped the future releases to go faster as the Scrum Team grew more confident in making changes to the code. They relied a lot more on machine feedback rather than error-prone human cycles.
Do not cut corners and sacrifice quality for speed. This only increases your technical debt, for which you have to pay dearly in the future. Your initial gain and more will be lost in the future when you struggle with existing implementation. Steve McConnell gets it right: “The problem with quick and dirty . . . is that dirty remains long after quick has been forgotten.”30
We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right [in italics],
we value the items on the left [in bold] more.31
The Agile Manifesto for Software Development was created in early 2001 and has been revisited multiple times since, without any resulting changes as it was still considered relevant. It was created by 17 leaders from the software industry, including the creators of Scrum, Ken Schwaber and Jeff Sutherland. It represents the underlying values and principles of good software development. Until the Agile Manifesto, agile software development was not called “agile.” Until then it was usually referred to as light-weight.
At Agile 2008 in Toronto, Uncle Bob (Robert Martin) suggested in his keynote the addition of a fifth value:
Craftsmanship over crap
However, he realized that it doesn’t fit the pattern of preferring the left-hand side over the right-hand side:
The problem with my proposal is that it is not a balanced value statement. In the other four statements we value the second item. We just value the first item more. But in my proposed addition, we simply do not value crap at all.
So I hereby change my original proposal, which was made for dramatic effect, to:
Craftsmanship over execution
Most software development teams execute, but they do not take care.
We value execution, but we value craftsmanship more.32
In the end, it is all about creating the right product with the right quality.
Compare your answers from the beginning of the chapter to the ones below. Now that you have read the chapter, would you change any of your answers? Do you agree with the answers below?
Scrum is an agile process.
Scrum Teams do very little planning.
If a Scrum Team changes the Scrum framework, they are no longer doing Scrum.
If a Scrum Team adds to the Scrum framework, they are no longer doing Scrum.
Every Scrum event is time-boxed.
The development process is owned by the Development Team. The Product Owner does not have a say.
1. Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2017), 3.
2. Schwaber and Sutherland, Scrum Guide.
3. Ibid., 4.
4. Ibid., 5.
7. Ibid., 6.
8. Ibid., 7.
9. Sandy Mamoli and David Mole, Creating Great Teams (Raleigh, NC: Pragmatic Bookshelf, 2015), 4–5.
10. Schwaber and Sutherland, Scrum Guide, 7–8.
11. Ibid., 6.
12. Rachel Thompson, “Winning Supportyou’re your Projects,” MindTools, accessed February 28, 2018, https://www.mindtools.com/pages/article/newPPM_07.htm.
13. Schwaber and Sutherland, Scrum Guide, 15.
14. Ibid., 16.
15. Ibid., 17.
16. Ibid., 18.
17. Ibid., 16.
18. Ibid., 9.
19. Ibid., 10.
21. Ibid., 10–11.
22. Cover Your @$$.
23. Schwaber and Sutherland, Scrum Guide, 12.
24. Ibid., 13.
25. Thanks to Ty Crockett.
26. Schwaber and Sutherland, Scrum Guide, 14.
27. Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” 1986, Harvard Business Review, January 1986, https://hbr.org/1986/01/the-new-new-product-development-game.
28. Schwaber and Sutherland, Scrum Guide, 15.
29. Meriam Webster’s, s.v. “increment,” accessed February 28, 2018, https://www.merriam-webster.com/dictionary/increment.
30. Steve C. McConnell, Software Project Survival Guide (Redmond, WA: Microsoft Press, 1998).
31. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas, “Manifesto for Agile Software Development” (2001), http://agilemanifesto.org/.
32. Mike Bria, “Craftsmanship—The Fifth Agile Manifesto Value?,” InfoQ, August 20, 2008, https://www.infoq.com/news/2008/08/manifesto-fifth-craftsmanship.