Chapter 1

Professional Scrum

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Software is a complex problem. Therefore, Scrum is ideal for managing the development of software in order to find solutions in an adaptive way. Software development doesn’t generate the same output every time, given a certain input. Scrum embraces this fact, and because of its empirical nature, it promotes the use of experimentation in order to inspect and adapt.

Scrum is not a methodology or a process. It is only a framework. In other words, if you take Scrum and add your own complementary practices, such as acceptance test-driven development, what you will end up with is your process. Teams can leverage Scrum’s empirical attributes to regularly see the effectiveness of its practices and make changes accordingly. I will introduce you to many complementary practices in this book for your consideration.

Note Scrum is founded on empirical process control theory and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Lean thinking leads to reduction in waste while focusing on the essentials.

Even today, more than 60 years into the evolution of software development, the chances are still good that a medium-sized to large-sized software project will fail. Fortunately, our industry has finally noticed, understands, and has started to respond to this problem. Some organizations have improved their odds. Evidence shows that agile practices, such as Scrum, are leading these successes.

Tip Using a software development analogy, you can think of agile as being an interface. Agile defines four abstract values and 12 abstract principles (http://agilemanifesto.org). Although there are many ways to implement these values and principles, the Agile Manifesto does not describe them. Scrum does. You can think of Scrum as a concrete class that implements the agile values and principles through its roles, events, artifacts, and rules.

Agile teams know that they must continuously inspect and adapt—not just their product, but their process and practices as well. Being book-smart on Scrum, DevOps, and Microsoft’s tools is a good start. Having experience using them together in practice is better. Being able to identify and act on opportunities for improvement as you use them is awesome! It’s being a professional. That should be your goal. Don’t just settle for a project that doesn’t fail. Strive for completing the project better, with more value, and with more learning than the spectators thought possible.

The Scrum Guide

Scrum has been around since the early 1990s. During that time, Scrum’s definition and related practices have come from books, presentations, and professionals doing their best to explain it. Unfortunately, those messages were not always accurate and almost never consistent. Even the two creators, Ken Schwaber and Jeff Sutherland, were inconsistent at times. Scrum, as it has emerged today, doesn’t look like it did 25 years ago.

In 2009, Scrum.org codified Scrum by creating and publishing the Scrum Guide. This free guide represents the official rules of Scrum and is maintained by Scrum’s creators, Schwaber and Sutherland. It is very concise. In fact, the 2020 version PDF is only 14 pages. It is available in 30 languages and downloadable at https://scrumguides.org.

The Scrum Guide is a great reference that you can use even as you are reading this book. As you read the guide, you will see that Scrum is lightweight and quite easy to understand. Unfortunately, it is extremely difficult to master. The Scrum Guide will continue to be updated and may supersede the guidance you read in this chapter and the rest of the book.

Tip You can think of Scrum as being like the game of chess. Both have rules. For example, Scrum doesn’t allow two Product Owners just as chess doesn’t allow a player to have two kings. When you play chess, it is expected that you play by the rules. If you don’t, then you’re not playing chess. This is the same with Scrum. Another way to think about it is that both Scrum and chess do not fail or succeed. Only the players fail or succeed. Those who keep playing by the rules will eventually improve, though it will take time to master the game.

The Scrum framework consists of the Scrum Team and the associated roles, events, artifacts, and rules. Each of these elements serves a specific purpose, as you will see in this chapter. The rules of Scrum, as defined in the Scrum Guide, bind together these roles, events, and artifacts. Following these rules is essential to the success of a team’s ability to use Scrum and, more importantly, to the successful development and delivery of a high-value, high-quality product. Changing the core design or ideas of Scrum, leaving out elements, or not following its rules covers up problems and limits the benefits Scrum provides, potentially even rendering it useless.

Scrum is free and offered in the Scrum Guide. Scrum’s roles, events, artifacts, and rules are immutable, and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other practices, techniques, and methodologies. I often describe Scrum as “a framework within which a team can experiment with various complementary practices.”

The Pillars of Scrum

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed and known. Lean thinking reduces waste and focuses on the essentials. Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

Scrum combines four formal events for inspection and adaptation within a containing event—the Sprint. These events work because they implement the empirical Scrum pillars of inspection, adaptation, and transparency. I will cover events later in this chapter, but I want to spend a moment defining these three pillars of Scrum:

• ■   Inspection   The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its events. Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum’s events are designed to provoke change and improvement.

• ■   Adaptation   If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the item being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation. Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

• ■   Transparency   The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection. Inspection and adaptation without transparency is misleading and wasteful.

Scrum in Action

If you study the Scrum Guide, you can understand the components and related rules, but you won’t necessarily see how they flow together. Doing so requires you to actually experience Scrum while developing a product on a team. As a substitute for that experience, Figure 1-1 was created by Scrum.org to help illustrate the Scrum framework in action.

FIGURE 1-1 The Scrum Framework.

In Scrum, the product is the vehicle that delivers value. The product could be a service, a physical product, or something more abstract. The product has a clear boundary, known stakeholders, and well-defined users or customers. Software fits this definition nicely, although Scrum can be used for so much more than software. That said, and because this is also a book about Azure DevOps, I will be describing Scrum and Professional Scrum in the context of software being the product.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. An example of a Product Goal for software might be “to achieve 100k downloads from the app store.”

The Product Backlog is an ordered list of everything that is known to be needed to achieve Product Goals. It is the single source for any changes to be made to the product and it is emergent – meaning that it will evolve continuously due to variation in business conditions, the domain, and technology. Each item in this list is a Product Backlog item (PBI). For software, the Product Backlog includes features to be implemented, bugs to be fixed, and experiments to be conducted. The Product Owner is accountable for managing the product’s expectations, risks, and outcomes as well as ensuring that the Product Backlog is ordered (prioritized), made transparent (available), and understood.

The Developers collaborate with the Product Owner, and others as needed, during Sprint Planning and Product Backlog refinement to understand, estimate, and forecast PBIs. The Product Owner orders the Product Backlog according to one or more factors, such as ROI (value/size) of those PBIs, risk, business priority, dependency, and learning opportunity.

The Sprint is a fixed-length period of time that contains the other Scrum events. A Sprint should be one month or less in duration in order to lower risk and create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

The first event within a Sprint is Sprint Planning. In this timeboxed event, the Scrum Team collaborates to forecast and plan the work of the Sprint. The PBIs toward the top of the Product Backlog that can best achieve the Product Goal will be considered. The Scrum Team collaborates to forecast those items that it believes it can complete by the end of the Sprint. A Sprint Goal is crafted, and the Sprint Backlog emerges. The Sprint Backlog contains those forecasted items plus a plan for delivering them. The Sprint Backlog shows the work remaining in the Sprint at all times.

The bulk of the Sprint will be spent working to achieve the Sprint Goal through the development of the items in the Sprint Backlog. The rules of Scrum are fairly quiet on what occurs each day during development. The Developers must meet regularly for the Daily Scrum to synchronize on the plan for the next 24 hours.

If necessary, the Developers should also meet with the Product Owner to refine the Product Backlog. During refinement, items in the Product Backlog are given additional detail and estimates. This keeps the Product Backlog healthy so that the Product Owner can have more meaningful conversations with stakeholders, plan releases, and make better decisions on what to do next.

During the Sprint, the Scrum Team completes items in their Sprint Backlog according to the Definition of Done. This definition lists the practices and standards that must be met for every item before it can be considered complete. If a Definition of Done doesn’t already exist, then it is created by the Scrum Team. It’s important for everyone to understand the definition because it will be used to facilitate the inspection of progress and quality. Work that does not meet the Definition of Done is . . . not done, and cannot be released. It should also not be inspected at the Sprint Review.

Ideally, the Developers collaborate with the Product Owner throughout the Sprint to ensure that a great product emerges. If the Developers complete their forecasted work early, they should collaborate with the Product Owner to find additional PBIs to work on. Conversely, at the first inclination that the Developers suspect that they won’t be able to complete their forecasted work, they should collaborate with the Product Owner to identify and discuss trade-offs and modify the Sprint Backlog in a way that does not sacrifice quality or alter the Sprint Goal.

An Increment is a useful and valuable body of inspectable work that meets the Definition of Done. An Increment is made up of one or more of the done PBIs that were forecasted for the Sprint. The Increment is inspected during Sprint Review. The Product Owner may invite various stakeholders to the Sprint Review for their feedback. This feedback is captured and might end up as new items in the Product Backlog. Existing PBIs may also need to be updated or removed. Stakeholder feedback may influence the Product Owner’s decision on releasing, continuing development, or stopping it altogether. These latter decisions should be based on business reasons, not quality reasons. Regardless of when the Increment is released, the Scrum Team should always develop the Increment as though it were going to be released. This may include being released multiple times during the Sprint—which Scrum totally supports.

The last event in the Sprint is the Sprint Retrospective. This is an opportunity for the Scrum Team to inspect themselves and how they work in order to adapt their practices and process so that they can improve. If improvement experiments are identified, the team should create an actionable plan for the next Sprint. To ensure continuous improvement, the Scrum Team should identify at least one high-priority process improvement and enact it during the next Sprint. Nothing is out of scope during a Sprint Retrospective—people, relationships, process, practices, and tools can all be discussed. The Scrum Team may also decide to adjust its Definition of Done in order to increase quality. After the Sprint Retrospective, the next Sprint begins, and the cycle repeats.

Scrum Roles

The group of individuals who are responsible for, and committed to, building the product and meeting its goals is known as the Scrum Team. The Scrum Team consists of the following Scrum roles:

• ■   Product Owner

• ■   Developers

• ■   Scrum Master

If you think of the roles in terms of providing service, the Developers serve the Product Owner, whereas the Scrum Master serves everyone. Therefore, the Developers can exert a strong influence to select (that is, hire or fire) the Scrum Master. The Product Owner can exert a strong influence to select the Developers that they want doing the work (HR policies and procedures notwithstanding). Because of this separation of duties, the roles should be played by separate individuals. This mitigates any chance of a conflict of interest. Smaller teams may find it necessary to combine roles.

Developers

Developers are the professionals on the Scrum Team who are capable of designing, building, testing, and delivering a Done, releasable product. There are between three and nine Developers on a Scrum Team—a small enough number to enable them to easily communicate and be nimble, while being large enough to be cross-functional and collaborate in the complex space, such as software development.

A team with only two Developers doesn’t need Scrum, since they can simply communicate directly and be productive. Also, there is a greater chance that those two Developers won’t have all the skills required to do all the work. On the other hand, teams with more than nine Developers require too much coordination. These larger teams tend to generate too much complexity to derive value from Scrum’s empiricism. For situations with more than nine Developers, multiple Scrum Teams may need to be formed, or even a Nexus. I’ll talk more about the Nexus and Scaled Professional Scrum in Chapter 11, “Scaled Professional Scrum.”

Note The Product Owner and Scrum Master are not considered in this count of 3–9 Developers unless they are also a Developer who will be working out of the Sprint Backlog during the Sprint. Regardless, the Scrum Team is typically 10 or fewer people.

It’s important to note just because a person is playing the Scrum role of Developer, that does not necessarily mean that they are a developer in the classic sense—someone who develops/writes code. Depending on the task, they may be developing architecture, developing user interfaces, developing test cases, developing database schema, developing deployment pipelines, developing test results, developing installers, or developing documentation. Everyone develops something.

Table 1-1 lists the high-level activities that the Developers on a Scrum Team will perform.

TABLE 1-1 Developer activities within Scrum.

Activity	When
Collaborating with the Product Owner to forecast the Sprint’s work and craft a Sprint Goal	Sprint Planning
Collaborating with fellow Developers on a plan to implement the forecasted work	Sprint Planning, Daily Scrum, or as needed
Participating in the Daily Scrum	Daily
Developing the Increment according to the Definition of Done	After Sprint Planning and prior to Sprint Review
Collaborating with the Product Owner to refine the Product Backlog	During the Sprint as determined by the Scrum Team
Collaboratively identifying additional development when forecasted work is completed early	During the Sprint as needed
Collaboratively discussing trade-offs and creating a contingency plan for when forecasted work can’t be completed	During the Sprint as needed
Assisting stakeholders with inspecting the Increment and eliciting feedback	Sprint Review or any time during the Sprint as needed
Reflecting on the process and practices in order to identify experiments for improvement	Sprint Retrospective
Inspecting, adapting, learning, and improving—living the Scrum Values	Always

Don’t assume that a Developer will execute only those types of tasks they are good at or familiar with. For example, just because Dieter has a background in database programming, that doesn’t mean he’ll be the one executing those types of tasks. If, during the Sprint, it is decided that the next logical task to execute requires database programming and Dieter is not available, another Developer should jump in and take on that work if at all possible. During development, the person who is best suited to perform a given task will emerge based on many factors, including expertise and availability. It is for this reason that any Sprint Backlog estimates are made by the Developers as a collective, not individuals—even if those individuals are specialists or even experts within those domains. It’s also why a Scrum Team should have more than one Developer with a necessary skillset. I will dive deeper into this in Chapter 8, “Effective Collaboration.”

Tip I find very few Scrum Teams whose members refer to each other as “Developers.“ There is still a reflex to equate “developer” to programmer or coder. Our industry reinforces this. For these teams, and for the time being, using the term “team member” may be a suitable substitute—and be more inclusive for testers, designers, and other nonprogrammers.

As a collective, the Developers must be cross-functional. This means that there must be at least one Developer on the Scrum Team who has the necessary skill to execute every type of work required. In other words, the Developers—as a whole—must have all the skills needed to complete their work. Being cross-functional doesn’t mean that each Developer is cross-functional—although that would be awesome. Ideally, there will be more than one Developer who has a required skill. If not, then the team should strive to correct that by pairing and sharing, or by leveraging some other instructional techniques during development. Having only one Developer on a team with a key skill is a risk.

The composition of the Scrum Team does not change during the Sprint. If it must change, it should only change “in-between” Sprints. This is typically the result of a decision made collaboratively during the Sprint Retrospective. Changes may include adding a new team member, swapping a member with another team, removing a team member, or changing a team member’s role or capacity. Keep in mind that any change to the team composition is a disruption. Productivity may initially decrease for a time and then should (hopefully) increase again. If the Scrum Team tracks velocity or Throughput, the disruption will be apparent.

Note Velocity is a historical measure of PBIs that a Scrum Team has been able to deliver. Velocity can be measured in the number, size/effort (such as points), or business value of those items. Velocity of a single Sprint is not useful, but tracking it over several Sprints shows the general direction of productivity of a team. Once velocity has normalized, it can be useful in planning Sprints and releases. For example, if a team has an average velocity of 20 points per Sprint and the Product Backlog shows 12 PBIs totaling 96 points yet to be developed to reach a Product Goal, you can expect the release to be available in roughly five Sprints, or 2 1/2 months given a 2-week Sprint cadence. Velocity is not mentioned in the Scrum Guide and is considered a complementary practice. Teams may also consider tracking and using flow metrics such as Throughput as a measure of past performance. I’ll cover flow and flow metrics in Chapter 9, “Improving Flow.”

Fabrikam Fiber Case Study

The Developers on the Fabrikam Fiber Scrum Team consist of five cross-functional individuals with varying backgrounds, skill sets, and skill levels. They are Andy, Dave, Dieter, Toni, and Richard (yours truly). Andy and Toni have architecture, design, and some C# experience. Dave, Dieter, and I have solid C# experience. Dieter and I also have SQL and Azure development experience, including Windows PowerShell. As a team, we have all taken Scrum.org’s Professional Scrum Developer training and achieved passing assessment scores.

The Product Owner

The Product Owner represents the voice of the user. This means the Product Owner knows not only the product, its domain, its vision, and its goals, but also its users. Just knowing how the product works and what to fix is not enough to be a competent Product Owner. Good Product Owners are in touch with the needs of their users. Great Product Owners will actually share in their passion and feel empathy for their struggles and expectations. The Product Owner also represents the Developers to the organization—at least until the Developers are introduced and begin working with others in the organization directly.

Note Over the years I’ve heard that the Product Owner is the voice of the stakeholder or customer. Although true, I prefer thinking of the Product Owner primarily as the voice of the user. What’s the difference? The stakeholder is anyone who is interested in the product or its development. The customer is typically the one who is sponsoring or paying for the product. The user is the one who actually uses it. A Professional Scrum Product Owner strives to satisfy all stakeholders.

The Product Owner must represent the needs of the user and drive value in their direction, rather than just trying to satisfy the person writing the check. There is only one Product Owner on a Scrum Team, an arrangement that helps avoid confusion. When the Developers have a question about the product or need to be introduced to a stakeholder, their first instinct should be to talk with the Product Owner. The Product Owner may have to consult others for answers, especially for large and overly complex products. The Product Owner should be considered the go-to person for all questions about the product’s vision, value, goals, and functionality.

The Product Owner is responsible for maximizing the value of the product through the work of the Developers. The Product Owner’s primary communication tool for doing this is a refined and ordered Product Backlog. The Product Owner collaborates with the Developers on what and when to develop. Table 1-2 lists the common Developer interactions with the Product Owner.

TABLE 1-2 Developer interactions with the Product Owner.

Interaction	When
Collaboratively plan the Sprint and forecast PBIs.	Sprint Planning
Get product/domain questions answered and get introduced to stakeholders.	During the Sprint as needed
Refine the Product Backlog.	During the Sprint as determined by the Scrum Team
Collaborate to take on additional work.	During the Sprint as needed
Collaborate to plan contingency work.	During the Sprint as needed
Assist the Product Owner with inspecting the Increment and other emerging work.	During the Sprint as needed
Assist the Product Owner with stakeholder inspection and to elicit feedback.	At least during Sprint Review, but also during the Sprint as needed
Collaborate to inspect the Scrum Team’s practices and plan for improvement.	Sprint Retrospective
Collaborate to create the Definition of Done.	Sprint Retrospective

A common misconception—one that was corrected in the 2020 Scrum Guide—is that the Developers develop the product. In fact, it’s the Scrum Team that “develops” the product—through the cooperation and collaboration of everyone on the team.

Tip A Professional Scrum Product Owner should know the product, know the product’s domain, know the product’s customers, know the product’s users, know Scrum, have authority to make decisions related to the direction of the product, be highly available to the rest of the Scrum Team, and have good people skills. I’ve not yet met a Product Owner who ticked all of these boxes. I have met many Product Owners who wanted to improve in all these areas and work toward that goal.

Professional Scrum Teams understand the separation of duties between the Product Owner and the Developers and have come to rely on each role doing their part. Although the Scrum Guide doesn’t explicitly state that the Product Owner cannot be the Scrum Master or a Developer, I think that’s a good separation to maintain. Keeping the Product Owner focused on what to develop, the Developers focused on how to develop it, and the Scrum Master focused on ensuring that everyone understands and follows the rules of Scrum is a recipe for success.

Since the organization may hold the Product Owner accountable for the profit or loss of the product, the Product Owner should maintain a constant vigil for optimizing the product’s value. Professional Scrum Product Owners are engaging Product Owners. They continuously want what is best for their product and, more importantly, what is best for its users.

Fabrikam Fiber Case Study

Paula is the Product Owner of the Fabrikam Fiber web application. Having started as a technician, she knows the pain points of the product and the struggles of its users. This awareness inspires her to constantly improve and evolve the capabilities of the product. She even likes to brag that she’s the app’s most prolific user. Her vision is to improve Fabrikam Fiber one ticket at a time until most customers can get their issues resolved the same day. Paula is an informed and engaging Product Owner who is available when necessary and has the authority to make the necessary decisions. Paula has been using Scrum for about three years. She has been through Scrum.org’s Professional Scrum Foundations and Professional Scrum Product Owner training.

The Scrum Master

The Scrum Master fosters the Scrum Values, practices, and rules throughout the Scrum Team and the organization. The Scrum Master ensures that the Product Owner and the Developers are functional and productive by providing necessary guidance and support. The Scrum Master is also responsible for ensuring that Scrum is understood by all involved parties and that everyone plays by the rules.

Note The Scrum Master is not the same thing as a project manager—not even close. They are considered a manager—but of Scrum and its implementation, not of a project, or people, or the product. Therefore, they should be given authority to make changes and remove impediments.

The Scrum Master must be vigilant while giving the organization time to acclimate and realize the benefits of Scrum. This means keeping any dysfunctional (such as old “waterfall”) habits at bay. It also means keeping any unenlightened managers at bay, while continually quashing the illusion that command and control and opaqueness equate to better and faster value delivery. Sometimes the Scrum Master may become the de facto change agent, leading the effort of organizational adoption of Scrum. If this is the case, then the Scrum Master’s steadfastness must be able to scale. This also illustrates the need for a Scrum Master to have great interpersonal skills.

A Scrum Master can be called on to act as a coach, ensuring that the team self-manages and is functional and productive. This role may include shielding them from focus-busting interruptions and other external conflicts while also removing any impediments to their progress. The ability of the Scrum Master to serve the team by removing impediments to their success is a vital piece of Scrum.

As a servant leader, the Scrum Master achieves results by giving priority to the needs of the team. Scrum Masters may also be of service to stakeholders and others in the organization, helping them understand the Scrum framework and expectations from the various players. Servant leaders are often seen as humble stewards of the people and processes in which they are involved. By having a “What can I do for you today?” attitude, the Scrum Master fosters an environment of collaboration and respect, providing fertile soil for a high-performance Scrum Team. Lao Tzu, the ancient Chinese philosopher, said it best:

When the master governs, the people are hardly aware that they exist. Next best is a leader who is loved. Next, one who is feared. The worst is one who is despised. If you don’t trust people, you make them untrustworthy. The master doesn’t talk, they act. When their work is done, the people say, “Amazing: we did it, all by ourselves!”

The Scrum Master is not a technical role. Having a strong background in the pertinent domain (such as software development) is not necessary, though it can be helpful at times. Scrum Masters must really know Scrum—that’s their domain. That’s not negotiable. A good Scrum Master will also have good communication and interpersonal skills. They may have to facilitate interactions with other team members or enable cooperation across roles, events, or others in the organization. It’s important to have those soft skills. Keep this in mind when considering who might make a good Scrum Master. Table 1-3 lists the ways in which the Scrum Master serves the Developers.

TABLE 1-3 Ways in which the Scrum Master serves the Developers.

Service	When
Help facilitate Scrum events, when the Developers can’t/won’t facilitate for themselves.	During the Sprint as needed
Identify, document, and remove impediments.	During the Sprint as needed
Provide training, coaching, mentoring, and motivation.	During the Sprint as needed
Coach the Developers on self-management.	During the Sprint as needed
Be the Developers’ emissary to the organization.	During the Sprint as needed
Attend nonproductive but “required” meetings on the Developers’ behalf.	During the Sprint as needed
Shield the Developers from interruption and noise in order to protect their focus.	During the Sprint as needed
Be relied on less and less.	Over time as the Developers improve

Tip In my opinion, traditional project managers don’t make good Scrum Masters. Unfortunately, this is a common reflex for an organization adopting Scrum. For example, the decision makers decide to send “Roger,” their PMI-certified, Gantt chart–loving, Microsoft Project expert to Professional Scrum Master training. The expectation is that Roger will lead the change. What I’ve seen happen is that either Roger’s project management “muscle memory“ adversely affects the adoption of Scrum, or his old colleagues and managers do.

The duties of the Scrum Master may not require a full-time commitment. Professional Scrum Teams recognize this and may select a Developer to play the part-time role of Scrum Master. This role may rotate between other Developers over time. Full-time Scrum Masters may morph into a Developer or move on to assist other Scrum Teams as they emerge in the organization. The Scrum Master role is more flexible than the other roles in this regard. As long as a Scrum Team understands and follows the rules of Scrum and has access to someone who can perform the duties of a Scrum Master when needed, party on.

Tip The skills of a Scrum Master are unique and important. The best Scrum Master I ever met was a man named Brian. He didn’t have a business background or a technical background. He was formerly a drug and alcohol counselor, which meant that he could listen, encourage, motivate, and also tell when someone was slacking, not doing all they were capable of doing, or not telling the truth. Being a Scrum Master is a career choice for some. In my experience, they tend to be outgoing, motivated, and dedicated to continuously improving their skills as they serve the team. These Scrum Masters should remain just that and shouldn’t be dismissed or converted to another role. They will bring more value to the team and the organization as a full-time Scrum Master. They are worth their weight in sticky notes.

Fabrikam Fiber Case Study

Scott was brought on last year to serve as Scrum Master. Initially, he served another team, providing the necessary coaching in order to transform them into a high-performance, Professional Scrum Team. Management agrees that he’ll be a fine Scrum Master for Paula’s team. They also plan to use Scott to help other teams within the organization learn and adopt Scrum. Scott has many years of practical, hands-on Scrum experience with various companies and teams. He has been through several Professional Scrum training classes and is active in the Scrum.org community.

Stakeholders

Although not an officially defined role in the Scrum Guide, stakeholders include everyone else involved or interested in the development of the product. Stakeholders can be managers, directors, executives, board members, analysts, domain experts, attorneys, sponsors, members from other teams, customers, and users of the software. Stakeholders are very important. They represent the product’s necessity from various perspectives. They also drive the vision, goals, and usability of the product by influencing the Product Owner. Without stakeholders, who would use the product, pay for its development, or derive benefit from it?

In my experience, Developers can tend to discount nontechnical individuals. This is unfortunate—stakeholders should not be ignored. They should be engaged. That said, some stakeholders can take too much interest in the development effort and its status, becoming a distraction and killing focus. A lot of misunderstanding exists on when and why stakeholders and Developers interact. Reading the Scrum Guide, you might think interaction only occurs during Sprint Review. As you can see in Table 1-4, stakeholders and Developers can interact at multiple points throughout the Sprint.

TABLE 1-4 Developer interactions with stakeholders.

Interaction	When
Collaborate to refine the Product Backlog.	During the Sprint as determined by the Scrum Team
Collaborate to answer questions that Developers might have about a PBI (estimating, planning, designing, building, testing, etc.).	During the Sprint as needed
Collaborate to inspect the Increment and to elicit feedback.	At least during Sprint Review, but also during the Sprint as needed

Inspecting and providing feedback on the product, such as requesting a capability/feature, should involve the Product Owner. Inspecting and providing feedback on the development process, such as inquiring about status, should be handled by the Scrum Master. In other words, stakeholders should almost always be kept out of the development process—unless they are invited in by the Developers. Following this guideline will help protect the Developers’ focus.

Tip Burndown, burnup, or other analytics posted in a common area or on a dashboard are a great way to keep stakeholders informed. This keeps the interruptions of the Scrum Team to a minimum. If anyone has questions, the Scrum Master can educate them.

The Scrum Master should strive to keep stakeholders out of the various Scrum events, with the exception of the Sprint Review and maybe Sprint Planning. Stakeholders should not be involved in any planning, development, or refinement activities unless their input is required. Attendance to any event is by invitation of the Scrum Team only. Stakeholders should not attend the Daily Scrum, as its purpose is to allow the Developers to synchronize with one another on the upcoming work. Even the Product Owner’s presence at the Daily Scrum may be considered a distraction from its purpose.

Fabrikam Fiber Case Study

The Fabrikam Fiber company has been around a few years. It has changed its name once and has gone through a few reorgs. The primary stakeholders are its customers, who are users of the company’s primary value stream: internet connectivity. Along with the service technicians, other business units, including sales and marketing, are all stakeholders of the Fabrikam Fiber web app and its support of operations. Of the various groups of stakeholders, most are not technical when it comes to software. Some internal stakeholders, however, have deep expertise in the domain of hardware and networking. All stakeholders have been pretty open about providing feedback on the web application. Paula understands the importance of capturing customer feedback. To that end, she insisted on setting up a wish@fabrikam.com email address to receive email-based feedback. These emails are routed to a support person who triages the requests and then works with Paula to add PBIs to the Product Backlog.

Scrum Events

The Scrum framework uses events to structure the various workflows of incremental development. Each event is timeboxed, which means that there is a fixed period of time to execute the activities within that event. Timeboxing minimizes waste by ensuring that an appropriate amount of time is spent focusing on a particular activity. These Scrum events are meant to establish regularity and a cadence. They are also meant to minimize the need for wasteful or impromptu meetings that are not part of Scrum.

All Scrum events are a formal opportunity to inspect and adapt something. Inspecting allows the team to assess progress toward a goal, as well as identify any variance in their current plan. If an inspection identifies any unacceptable deviation, an adjustment (adaptation) must be made. These adjustments should be made as soon as possible to minimize further deviation. Failure to include or participate in any of the Scrum events results in reduced transparency and is a lost opportunity to inspect and adapt.

Referring back to Figure 1-1, you can see that there are five events in Scrum:

• ■   Sprint   A container for the other four events. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happens within a Sprint. Sprints are fixed-length events of one month or less. A new Sprint starts immediately after the conclusion of the previous Sprint.

• ■   Sprint Planning   Initiates the Sprint by laying out the work to be performed for the Sprint. This planning is performed through the collaborative work of the entire Scrum Team.

• ■   Daily Scrum   Used to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Only Developers participate in the Daily Scrum.

• ■   Sprint Review   Used to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders, the Product Backlog is updated, and progress toward the Product Goal is discussed.

• ■   Sprint Retrospective   Used to plan ways to increase quality and effectiveness.

Note A notion exists that the Sprint is that time period after Sprint Planning and ending before the Sprint Review in which the actual development occurs. This is incorrect. The Sprint is actually an outer “container” for the four other events. This means that the Sprint has already begun when Sprint Planning commences. The time between Sprint Planning and Sprint Review doesn’t technically have a name, but most refer to it as “development.” The Sprint concludes after the Sprint Retrospective, and then starts again with the next Sprint Planning.

The Sprint

A Sprint is the set period of time in which an Increment of the product is developed. A Sprint is Scrum’s term for an iteration. Sprints are one month or less in length and run end to end, one after another. The frequency of feedback, experience and technical excellence of the team, and the organization and Product Owner’s need for agility are key factors in determining the length of a Sprint. For example, if the product is an enterprise desktop application with fairly well-defined goals and not much deviation in plans, longer Sprints are fine. If the application is a cloud-based software as a service (SaaS) product with several competitors and demanding customers, shorter Sprints are more desirable. The stakeholders and the Scrum Team must collaborate to determine the ideal length of the Sprint.

Sprint Planning, development, Daily Scrums, the Sprint Review, and the Sprint Retrospective all take place within the Sprint. After you start using Scrum, you are always in a Sprint—assuming there is still a product, stakeholders, and a desire to invest in new capability. When a Sprint Retrospective ends, the next Sprint begins and you repeat the inner events again. There should never be any breaks in between Sprints.

I asked Ken Schwaber once how long a Sprint should be. His answer was, “as short as possible and no shorter.” Sprints of longer than four weeks (one month) have a smell—the smell of water falling. When a Sprint’s length is longer than a month, the definition of what is being built may change or complexity and risk may increase. By limiting the maximum length of a Sprint, at most one month of development effort would be wasted, rather than several months in a classic, “waterfallian” project.

Conversely, Sprints with a length of less than one week are possible but should be executed only by high-performance Professional Scrum Teams. Even with very short Sprints, the overhead of the inner events must be factored in, leaving even less time—as a percentage—for actual development. Teams working in ”micro Sprints” like these need to be on their A-game every day.

Ideally, the length of the Sprint does not change. If it must, it can only change in between Sprints, as a result of a decision made during a Sprint Retrospective. Any change to the length of a Sprint will cause disruption to the Developers’ cadence, thus impacting forecasts and plans. Although this will correct over time, it’s not a good idea to constantly introduce such chaos.

Each Sprint is like a mini-project. In fact, when I’m introducing Scrum to a new organization or team, I suggest replacing their use of the term “project” with “Sprint” or “Sprints” in conversation. For example, instead of referring to the “CRM integration project,” just refer to that initiative as Sprints 17–19, where PBIs relating to CRM integration will be forecasted and developed.

The Sprint has a definition of “what” is to be developed. It also includes a flexible approach on “how” to develop it. During the Sprint, all aspects of the development work are executed. With a software product, this will typically be more than just designing, coding, and testing. The scope of work may be clarified as more is learned, and the Product Owner may collaborate with the Developers to renegotiate and add new items or swap different items in the Sprint Backlog—as long as they fit with the Sprint Goal. The Developers may not decrease any quality goals in order to finish its work. The resulting product Increment is produced, inspected by stakeholders, and perhaps even released.

The choice of which day of the week to start (and end) a Sprint is entirely up to the Scrum Team. Some practitioners prefer Mondays or Fridays. I prefer midweek so that the chances are highest that the whole team will be present and participating with maximum focus. Events can be rescheduled around holidays, but I recommend the Sprints remained fixed. For example, if Sprint 26 ends during a company holiday, leave its start and end date alone to maintain the two-week cadence, and just schedule the Sprint Review and the Sprint Retrospective at the end of the first week. Minor adjustments like these may need to be done throughout the year.

Fabrikam Fiber Case Study

Originally, the Scrum Team tried four-week Sprints. They felt that the longer timebox would be closer to the quarterly delivery schedule they had been accustomed to. Unfortunately, since the team was new to Scrum, they continued to take a sequential approach to development. They spent a lot of time on analysis and design at the beginning of the Sprint and deferred testing until the end. The resulting crunch in the last days of the Sprint was not sustainable and was really just a backslide into waterfallian habits (also known as “Scrummerfall”). The team did not experience the productivity gains everyone anticipated. When they brought on Scott (the Scrum Master), he recommended moving to two-week Sprints. This caused the developers to experience an increased sense of urgency and change the way they worked, maintaining a comfortable level of intensity throughout the Sprint. Scott also recommended starting the Sprint on a Wednesday. This change increased the chances of the whole team being available and operating at peak focus. It also allowed stakeholders to fly in for an in-person Sprint Review and subsequent Sprint Planning without having to stay over a weekend. The Scrum Team has completed many successful Sprints while on this two-week cadence.

Sprint Planning

Sprint Planning is for selecting and planning the work that will be performed during the Sprint. This is the first event that occurs within the Sprint. The entire Scrum Team attends and participates. A refined and ordered (prioritized) Product Backlog is required as an input for Sprint Planning. Developers collaborate with the Product Owner on the scope of work that can be accomplished. This is called the forecast. The forecasted work, along with a Sprint Goal and a plan for doing the work, are the outputs. The Sprint Backlog holds these outputs.

Sprint Planning is timeboxed, so everyone needs to be laser-focused. Distractions, such as off-topic conversations, should be minimized. The maximum length of Sprint Planning is eight hours but, in practice, the length should be a function of the length of the Sprint, as you can see in Table 1-5.

TABLE 1-5 Length of Sprint Planning.

Sprint length	Sprint Planning length
4 weeks	~ 8 hours or less
3 weeks	~ 6 hours or less
2 weeks	~ 4 hours or less
1 week	~ 2 hours or less
Less than a week	In proportion to the above lengths

Sprint Planning consists of three topics. Each topic answers a question: why, what, and how. Each question is answered by an output of Sprint Planning. Why is answered with the Sprint Goal. What is answered with the forecast. How is answered with the plan. The following pages will go into detail on each of these topics.

Topic 1: Why is this Sprint valuable?

During Sprint Planning, the Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal is an objective, in narrative format, that guides the Developers as they develop the Increment. The Sprint Goal also provides stakeholders the ability to see a synopsis of what the Scrum Team is working on. The Sprint Goal must be finalized prior to the end of Sprint Planning.

Although the Product Owner may bring the Product Goal and other business objectives into Sprint Planning, it’s important that the whole Scrum Team finalize the Sprint Goal together and agree on its verbiage and meaning. Everyone on the Scrum Team should then commit it to memory. Stakeholders should have access to it as well. After development has begun (that is, Sprint Planning is over), the Sprint Goal should not be changed. It is the theme that the team commits to achieving. If the Developers aren’t able to achieve the Sprint Goal, or the goal becomes obsolete, the Product Owner might decide to cancel the Sprint—another indication of the Sprint Goal’s importance. Cancelling a Sprint is discussed in Chapter 6, “The Sprint.”

The Scrum Guide doesn’t say which comes first, the Sprint Goal or the forecast. Some Scrum Teams like to craft the Sprint Goal first, or at least in parallel with the forecasting of work. This way, there is more cohesion with the goal and the PBIs that are developed during the Sprint. This cohesion makes it easier to understand the value of the Increment and how it fits into the goals of the product or release. Other teams may want to forecast the highest-ordered items in the Product Backlog and then craft a narrative Sprint Goal around those items. Both approaches can be difficult for teams who need to deliver disparate features and bug fixes for a given Sprint.

The Sprint Goal gives the Developers some flexibility and guidance about the functionality implemented within the Sprint. Even if they deliver fewer PBIs than were forecasted in Sprint Planning, they can still achieve their Sprint Goal. For example, let’s say the Developers forecast the following PBIs during Sprint Planning:

1. Add a Twitter feed to the homepage.

2. Create a Facebook page for the company.

3. Create and host a wiki for product support.

Given this forecast, the Sprint Goal might read, “To increase community awareness of our company and its products” or simply, “Socialize Fabrikam Fiber.” As the Developers work, they keep this goal in mind. If the team is unable to finish the third PBI (wiki), they didn’t fail because they were still able to achieve the Sprint Goal by completing the first two PBIs.

If it sounds like Sprint Goals give the Developers “wiggle room,” you are correct. Remember that what developers do is difficult and full of risk. That’s why they should forecast the individual items they think they can deliver but commit to the Sprint Goal that embodies them.

Note The Sprint Goal should not be too broad, such as “To improve the product.” Nor should the Sprint Goal be too specific, such as “To implement PBI #1 and PBI #2 and PBI #3 and PBI #4 and PBI #5 . . .” It may be difficult to achieve vague Sprint Goals, and compound Sprint Goals tend to split the team’s focus and not allow flexibility. A Sprint Goal should describe the reason for undertaking the Sprint, not just a review of the forecasted PBIs. A good Sprint Goal helps a team understand the purpose and impact of the work they are doing, which is a motivator.

Topic 2: What can be done in this Sprint?

During Sprint Planning, the Developers consider the highest-ordered PBIs from the Product Backlog one at a time. The order is decided by the Product Owner. Each PBI’s details and acceptance criteria are discussed. Clarification is provided by the Product Owner as well as other stakeholders, who may be able to provide domain expertise and clarification.

After obtaining a sufficient understanding of the PBI, the Developers collaborate to determine whether the PBI is small enough to fit into their Sprint capacity. If the Developers honestly believe that they can deliver the item in this Sprint—according to their Definition of Done—the item is added to the forecast. This may require estimation or use of a flow metric such as Service Level Expectation. I’ll discuss flow and flow metrics in Chapter 9.

If the Developers are not in agreement on whether an item should be forecasted, this may require the PBI to be further analyzed and discussed. It may end up being split or deferred until a later Sprint, when more is known. The Developers then move to the next item—in order—in the Product Backlog. Since the Product Owner is part of Sprint Planning, the order of the items in the Product Backlog can be updated as needed.

This process of forecasting is repeated until the Developers think that they have a comfortable amount of work for the Sprint, given their capacity/availability, past performance, and other factors. These forecasted PBIs are moved from the Product Backlog to the Sprint Backlog.

New Scrum Teams that don’t yet have a handle on their past performance may just use their instinct to decide what feels like the right amount of work. High-performance Professional Scrum Teams may do the same. If, during the Sprint, the Developers complete their forecasted work early, they should collaborate with the Product Owner mid-Sprint to identify and develop additional PBIs. Ideally, these items should align with the Sprint Goal. The Developers should never forecast more work than they know they can complete.

Note In 2011, the Scrum Guide introduced a somewhat controversial change to Sprint Planning. The word ”commit” was replaced with ”forecast.” Scrum practitioners had an issue with the word ”commit” for some time. The problem was that ”commit” implied that the team was obligated to deliver all PBIs at the end of the Sprint. This was especially true when stakeholders, who tend to not understand the complexities of developing complex products such as software, heard the word. Since complex product development is difficult and full of risk, delivering all PBIs every Sprint is unrealistic. The Developers might have to cut quality in order to make good on their “commitment”—and that is forbidden in Scrum, as well as in ethical product management.

The term ”forecast” is more realistic and easier to understand by stakeholders who have probably heard terms like “sales forecast.” It suggests that, although the Developers will do their best, given what they know new information may emerge during the Sprint that might impede their best-laid plans. If you and your organization still use the term “commit,” it may take some time to get used to the term “forecast.” It may sound like a weasel word to some, but overall, its usage is more honest and transparent.

Topic 3: How will the chosen work get done?

Sprint Planning is not complete until the Developers have also devised a plan for how they will develop the forecasted PBIs. The plan must ensure that all PBI acceptance criteria are satisfied while meeting the Definition of Done. The plan might be visualized as a collection of sticky notes in the same row as the associated PBI sticky note. In a software tool, such as Azure DevOps, it might be several child records related to a parent record. Regardless of the tool the team uses, the Sprint Backlog contains the Sprint Goal, the forecasted PBIs that will achieve the Sprint Goal, and the plan (tasks, tests, diagrams, etc.) to develop those PBIs.

Tip Go lightweight during Sprint Planning. Whiteboards are a great medium for sketching ideas and brainstorming tasks. Laptops aren’t. Whiteboards can be easily photographed and wiped clean afterward. Files on laptops or work items in Azure Boards tend to linger and yearn to be kept and updated. They also indicate a finality set in stone that is not necessarily the truth. Using sticky notes to brainstorm the plan is also good. They can be moved and removed easily from the board. A Professional Scrum Team will avoid using any tool during Sprint Planning unless its value outweighs its distraction factor. Sticky notes and whiteboard sketches can be translated later, after the Developers agree on a plan.

Because of the Sprint Planning timebox, the Developers probably won’t be able to identify every detail required to develop each PBI. For expediency creating the plan, a minimum amount of information should be recorded—perhaps just a title and estimate of effort. Sprint Planning is not the time for detailed design. Instead, the Developers need to focus on the high-level plan. Implementation details will emerge throughout the Sprint.

For example, let’s assume that the team will have to create several entity models, controllers, and views. Rather than go down a design “rat hole” during Sprint Planning, Developers should just identify a couple of high-level tasks: create models, create views, and so forth. If the Developers estimate time for those tasks, those estimates would simply be an aggregate of effort to perform all the related activities per task.

Assuming the Developers are using tasks to formulate the plan, the tasks to be executed earlier in the Sprint should be more decomposed and detailed than those further down the Sprint Backlog. Estimates, if the Developers decide to use them, can be in whatever unit of measure they decide. For tasks, hours are the most common unit. I’ve also seen teams use days or task points (similar to story points). Personally, I think using points for estimating tasks can lead to confusion. Rarely would you want to relatively compare the estimates of two tasks that could end up being done by different team members. Regardless of the unit of measure, all of these numeric values will power a Sprint burndown chart, should the team choose to employ one. I’ll cover estimating (sizing) in Chapter 5, “The Product Backlog.”

It’s important for the Developers to leave Sprint Planning with the why, what, and how—all of which is documented in the Sprint Backlog. As you will learn in Chapter 6, task ownership is not a required outcome of Sprint Planning. In fact, it’s better to leave “to do” tasks unassigned so that team members who have capacity can pick a relevant task to work on next. That said, it is common for each Developer to own a task prior to leaving Sprint Planning. The Developers will then self-manage to undertake the work in the Sprint Backlog as needed throughout the Sprint.

Fabrikam Fiber Case Study

The first Sprint Planning sessions were chaotic. The Developers were introduced to new PBIs for the first time at Sprint Planning. Paula (the Product Owner) wasn’t always prepared and the domain experts were sometimes unavailable. Most of Sprint Planning was spent understanding what was to be developed, and planning the how got deferred until the first few days of the Sprint. The why (Sprint Goal) was missing in several early Sprints as well. With coaching from Scott, the Scrum Team improved over time as everyone got used to Scrum and got into a cadence. Sprint Planning also became more efficient when the team started meeting regularly to refine the Product Backlog.

The Daily Scrum

The Daily Scrum is a 15-minute, timeboxed meeting for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next 24 hours of work. The Daily Scrum should be held on all working days of the Sprint—even on days containing Sprint Planning, Sprint Review, and Sprint Retrospective events.

Daily Scrums improve communications, identify impediments, promote quick decision making, and consequently eliminate the need for other meetings. The Daily Scrum allows Developers to listen to what other Developers have done and are about to do. This leads to increased collaboration, as well as accountability. If one Developer hears that another Developer is about to work in a similar area of the product, they may choose to pair up for the day. On the other hand, if the team hears that a Developer is on day 3 of a two-hour task, it may be time to pair up or inquire about the root cause of the delay. Developers need to understand that commitments are being made at this meeting and that these commitments will be tested 24 hours from now.

Note I hear a lot of teams refer to this event as the “daily standup.” It’s called the “Daily Scrum.” If the team decides to stand, they may do so. They can also sit, squat, or plank.

The Developers can use the dialogue heard during the Daily Scrum to assess their progress. By hearing what is or isn’t being accomplished each day, the team can determine whether they are on their way to achieving the Sprint Goal. As teams improve in their collaboration, this vibe will become more noticeable—even outside the Daily Scrum. High-performance Professional Scrum Teams may even outgrow the need for a formal assessment tool such as a Sprint burndown.

The Daily Scrum should be held in the same place and at the same time every day to reduce complexity and to maximize the likelihood of attendance. Ideally, the Daily Scrum is held in the morning so that the Developers are able to synchronize their work for that day. Dislocated teams may need to be more flexible in their start times.

The Daily Scrum is not a status meeting. Problem solving should not be attempted at the Daily Scrum because it can often lead to the team violating the 15-minute timebox. Those conversations should be deferred until after the Daily Scrum. Use a parking lot or other practice to track off-topics. A parking lot is a tool, such as a whiteboard or wiki, to capture comments or questions not related to the agenda. In the case of the Daily Scrum, this would be anything not related to inspecting progress or adjusting the Sprint Backlog.

The Daily Scrum is not meant for anyone other than the Developers to participate. This includes the Product Owner. In fact, the Scrum Master is not even required to attend. The Scrum Master needs only to ensure that the Daily Scrum takes place and that the rules are followed. Any impediments can be identified, tracked, and even mitigated by a Developer. If the Product Owner or Scrum Master is actively working on items in the Sprint Backlog, then they are considered a Developer and will participate in the Daily Scrum.

Tip Keep laptops, boards, burndown charts, and other tools or artifacts out of the Daily Scrum. These tend to distract from the purpose of the Daily Scrum—which is to synchronize with one another. Each Developer should know their own information without having to look up anything. Observations and impediments can be recorded on a whiteboard or by using sticky notes. High-performance teams will use a parking lot to track anything not relevant to the Daily Scrum, and follow-up conversations can tackle those issues. The Developers are self-managing and can decide to meet formally or informally at any time during the day for any reason. In fact, the Scrum framework has no guidance on what the Developers do the other 7 hours and 45 minutes of the day. I would hope they would interact with other individuals as necessary in order to build an awesome product.

Fabrikam Fiber Case Study

The Developers have their Daily Scrum at 9 a.m. each day. Before the meeting, each Developer updates their work remaining estimates on their tasks on the board. Doing so gives them a fresh perspective on their remaining work and enriches the conversation. A side benefit is that this keeps the burndown reports accurate, which is good if they are consulted throughout the day. The actual Daily Scrum finds each Developer talking briefly about what they’ve accomplished yesterday and what they plan to do today. Any impediments are also raised. Sticky notes are created and placed in a parking lot as needed. The Daily Scrum usually takes less than 10 minutes. Scott rarely shows up anymore.

Sprint Review

After the Sprint’s development timebox has expired, a Sprint Review is held. The entire Scrum Team attends, as well as any stakeholders the Product Owner invites. This informal meeting is for inspecting the Increment developed by the team. Stakeholders get to observe an informal demonstration of—or get their hands on—working product. Their feedback is elicited and captured. This collaboration can yield new, updated, or removed PBIs. Progress toward the Product Goal is also discussed, as everyone collaborates on what to do next. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a simple demonstration or presentation.

The Sprint Review is timeboxed to a maximum length of four hours. For shorter Sprints, the Sprint Review is usually shorter. In practice, the length should be a function of the length of the Sprint—essentially half that of Sprint Planning—as you can see in Table 1-6.

TABLE 1-6 Length of the Sprint Review.

Sprint length	Sprint Review length
4 weeks	~ 4 hours or less
3 weeks	~ 3 hours or less
2 weeks	~ 2 hours or less
1 week	~ 1 hour or less
Less than a week	In proportion to the above lengths

During the Sprint Review, the Sprint Goal and forecasted PBIs should be restated. Keeping their audience in mind, the Scrum Team may give a short summary about what went well, what didn’t, and how they overcame any problems. Completed PBIs are inspected through demonstration or by having the stakeholders interact directly with the product. Inspection should not be done by showing secondary artifacts, such as slides, mock-ups, diagrams, or passing tests. Because this is a working session, the Scrum Team may need to explain what the stakeholders are seeing and answer any of their questions.

Tip The Developers should never surprise their Product Owner at a Sprint Review. In other words, this should not be the first time the Product Owner sees the completed work. Professional Scrum Teams know the value of collaboration with the Product Owner. At a minimum, the Developers should ask the Product Owner’s opinion on individual PBIs as they approach completion throughout the Sprint. There is no built-in Product Owner “acceptance” in Scrum. Should a Definition of Done include it, however, don’t delay until the end of the Sprint—or Sprint Review—to obtain it. You don’t want a Sprint Review to become a “sign-off” meeting. Sprint Reviews are more about improving the product through collaboration and feedback.

A Sprint Review can generate one or more outcomes:

• ■   Feedback (new requests, ideas, experiments, or hypotheses) is added to the Product Backlog.

• ■   Unnecessary items are removed from the Product Backlog.

• ■   The Product Backlog is refined.

• ■   The Product Backlog is reordered.

• ■   The Product Owner decides to release the Increment.

• ■   The Product Owner decides to turn on a feature flag.

• ■   The Product Owner decides to cancel development.

As previously mentioned, the Sprint Review is an informal meeting. The Scrum Team should not spend much time preparing for it. Nobody should feel like they are attending a technical presentation at a conference. On the other hand, the team should be organized enough so that it doesn’t waste the stakeholders’ time. If necessary, the Scrum Master can intervene and make corrections to maximize the meeting’s value for everyone. Any process corrections can be discussed at the Sprint Retrospective and implemented in the next Sprint.

There are many ways to run a Sprint Review. Some Scrum Teams like it to have some structure. Others don’t. Some like the Scrum Master to kick it off. Others like it to be the Product Owner. Some like to rotate Developers so everyone gets a chance to talk and drive the review. Others like their strongest communicator driving. Still others like stakeholders to put hands on the product directly. Regardless, the Sprint Review should be down to earth and foster an environment of collaboration and discussion. The Scrum Team should be inquisitive, and all feedback should be welcomed and captured. Later, the Product Owner can go through the feedback, adding description and detail. Inane ideas will eventually sink to the depths of the Product Backlog or be deleted altogether.

Being mindful of the timebox, the Scrum Team can discuss unfinished or not started PBIs with the stakeholders. If the stakeholders have blocked time out of their busy day, don’t squander an opportunity to get their feedback on PBIs that might be coming up in an approaching Sprint. These refinement discussions can generate valuable input for planning.

Fabrikam Fiber Case Study

Sprint Reviews have always been a big deal for the Scrum Team. They meet every other Tuesday morning, inviting all the pertinent stakeholders and sometimes members from other teams. Paula (the Product Owner) kicks off the meeting with a review of the Product Goal, Sprint Goal, and the forecasted work for the Sprint. Scott (the Scrum Master) then gives a summary of the Sprint, including the team’s progress (using analytics), any obstacles that emerged, and how the Scrum Team overcame them. The bulk of the typically hourlong review is spent by the stakeholders inspecting the completed functionality. This is typically done through demonstration—in a storytelling way, with the Developers playing different personas as they take various journeys through the product. This engaging approach makes everyone in the room feel safe and comfortable in sharing their opinions and ideas. Feedback is captured by members of the Scrum Team. Stakeholders sometimes send feedback after the Sprint Review as well. Paula then wraps up by discussing her ideas for the next Sprint and updates everyone on progress toward the Product Goal. The Sprint Reviews are recorded, and those videos are shared with others who couldn’t attend.

Sprint Retrospective

The last event in the Sprint is the Sprint Retrospective, where the Scrum Team will inspect and adapt its own behavior and practices, looking for opportunities to improve. The Sprint Retrospective occurs after the Sprint Review but before the next Sprint Planning. The exact time and location are up to the Scrum Team. It’s important for the Product Owner, Scrum Master, and all Developers to attend—but not stakeholders. Having stakeholders in the Sprint Retrospective may cause transparency to drop. The maximum length of a Sprint Retrospective is three hours but, in practice, the length should be a function of the length of the Sprint, as you can see in Table 1-7.

TABLE 1-7 Length of the Sprint Retrospective.

Sprint length	Sprint Retrospective length
4 weeks	~ 3 hours or less
3 weeks	~ 2.25 hours or less
2 weeks	~ 1.5 hours or less
1 week	~ 45 minutes or less
Less than a week	In proportion to the above lengths

The purpose of the Sprint Retrospective is for everyone to share their observations, thoughts, and ideas on what went well and what didn’t with regard to people, relationships, process, tools, and so forth. These discussions can get deep and sometimes heated, especially when you are talking about social interactions with individuals. The meeting should remain constructive, and it’s the Scrum Master’s responsibility to keep it that way.

Note Impediments and struggles with the development process and practices can be inspected and adapted at any time, such as during the Daily Scrum or throughout the day. The Sprint Retrospective provides the formal opportunity for such inspection, as well as time for planning any adaptations.

The output of a Sprint Retrospective is a plan for implementing improvements. These improvements can target the development process as a whole or individual practices within it. Improvements might include changing the way the Developers work, where, or when. Improvements might also include changing how the Developers use their tools or what tools they use. Adaptations might be more social in nature, such as experimenting with ways to make the team environment more or less stimulating.

Any potential improvement is just an experiment, since the Scrum Team constantly inspects and adapts its practices. Some of these changes can be pretty disruptive, so they should be executed only with the consensus of the full Scrum Team having a complete understanding of the ramifications of making the change. Any change made must still abide by the rules of Scrum. Table 1-8 lists some changes that the Scrum Team might make during a Sprint Retrospective.

TABLE 1-8 Changes that can be made at the Sprint Retrospective.

Change	Example(s)
Increase product quality by updating the Definition of Done.	Adding a rule that code coverage cannot decrease as new code is pushed
Change the person playing the Scrum Master role.	Relieving Scott of his duty while attributing the role to Dave
Change the team composition.	Adding another Developer or dropping Toni’s capacity to 50%
Change the Sprint length.	Changing from three weeks to two weeks

Tip Don’t just hold a Sprint Retrospective for the sake of checking a box. If problems are identified, make sure improvement experiments are also identified. If improvement experiments are identified, make sure that they are actually performed in the next Sprint. Inspect, adapt, and repeat! I’ll go deeper on this in Chapter 10, “Continuous Improvement.”

A Scrum Team can choose from among many techniques during a Sprint Retrospective. The most common is to have Scrum Team members answer three questions:

• ■   What did we do well this Sprint?

• ■   What could we have done better?

• ■   What will we do differently next Sprint?

There are other approaches to start the conversation, elicit feedback, and brainstorm ideas. Entire books and websites have been devoted to running successful retrospectives. Table 1-9 lists some of the techniques that my fellow Professional Scrum Trainers have employed successfully. You can search the web for additional information, such as the instructions for using each technique or how they may be combined.

TABLE 1-9 Sprint Retrospective techniques and activities.

Technique	Description
Timeline	A timeline for the Sprint is marked on a wall, and team members add sticky notes to it to indicate good and bad events that occurred at that point in time.
Emotional Seismograph	Similar to the Timeline, but team members mark their emotional level as a high or low point on a y-axis throughout the Sprint.
Happiness Metric	Similar to the Emotional Seismograph, but team members track their happiness levels throughout the Sprint using a scale of 1–5 with comments. A chart is produced for the Sprint Retrospective, and the peaks and valleys are discussed.
Mad, Sad, Glad	Team members brainstorm on the events that made them mad, sad, or glad during the Sprint. Sticky notes are combined, grouped, and discussed.
The 4 L’s	Four posters or whiteboards are created for Liked, Learned, Lacked, and Longed For. Team members add sticky notes to the respective board. They are grouped and discussed.
The 5 Why’s	A question-asking technique used to explore cause-and-effect relationships underlying a particular issue or impediment.
Remember the Future	Used to create a vision of what the team wants to achieve by inquiring about a future point in time that follows another future point in time where the hypothetical change was made.
Car Speeding Toward Abyss	A technique in which you draw a picture of a speeding car heading toward an abyss and use this analogy to identify the engine, parachute, abyss, and bridge comparisons to the Scrum Team’s current situation. The Speedboat and Sailboat are variations of this technique.
Perfection Game	A technique used to maximize the value of ideas. Team members rate an idea from 1 to 10 and provide positive feedback on how to make it a 10. No feedback means they’ve given it a 10.
Fishbowl	Arranging chairs in an inner and an outer circle in order to attract team members to an empty chair in the inner circle (the fishbowl) and participate in the conversation.
Starfish	Using a starfish diagram, team members add sticky notes in these categories: do the same (=), do less of (<), stop doing (–), start doing (+), do more of (>). The findings are normalized and discussed.
Problem Tree Diagram, or Ishikawa (Fishbone) Diagram	A technique for visualizing the cause-and-effect relationships pertaining to a particular problem.
Team Radar	The team defines the factors (feedback, communication, collaboration, etc.), and then each team member rates their interpretation of that factor on a scale of 0–10, where 0 means not at all and 10 means as much as possible. The chart is discussed and saved for later comparison.
Circles and Soup	A technique for helping identify what is and what is not the responsibility of the Scrum Team. This is similar to the Circle of Concern and Circle of Influence techniques.

It’s also important during the Sprint Retrospective to celebrate the team’s victories. The good things that occurred should be encouraged to persist. Likewise, challenges during the Sprint should be seen as opportunities for victory in the next. This continuous improvement mindset is foundational in a Professional Scrum Team, and they live it every day. Since not every team member is wired this way, respect, encouragement, and team building are important and should be part of the Sprint Retrospective, too, if necessary.

Fabrikam Fiber Case Study

In the early Sprints, the Sprint Retrospectives would not generate much return on the time invested. The entire Scrum Team would go through the basic questions. To them, it just felt like a longer version of the Daily Scrum and a waste of time. Retrospective notes were captured and sometimes a plan for improving was executed. When Scott joined as Scrum Master, this changed. He introduced new techniques to get everyone involved. He focused on what went well and on team building. He also worked hard so that any action items were implemented during the following Sprint.

Product Backlog Refinement

Maintaining a well-refined Product Backlog helps the development of a successful product. Product Backlog refinement is the periodic meeting of the Product Owner and the Developers to add detail to upcoming PBIs. This is the time when the requirements and acceptance criteria are explored and revised. When the Developers have sufficient understanding of a PBI, they are then able to estimate its size—or at least determine whether it is small enough to fit into a Sprint. This estimate may change over time as more is learned about the item. In fact, the Developers may continue to refine and estimate the same PBI several times before they deem it “ready.”

Although Product Backlog refinement is a necessary and important part of product development, it is not a formal event in Scrum. It is optional. If the Scrum Team decides to refine the Product Backlog, it should take no more than 10 percent of the capacity of the Developers (for example, no more than 8 hours total spent refining for an ideal, two-week Sprint). The exact where and when of refinement are left up to the Scrum Team to decide.

Some teams try to avoid a refinement near the beginning or end of the Sprint so that it doesn’t collide with the Scrum events. It is important to have the entire Scrum Team—including all Developers—involved in refinement because the analysis, conversation, and learning will be more meaningful. Diligently refining the Product Backlog minimizes the risk of developing the wrong product.

Fabrikam Fiber Case Study

With the adoption of two-week Sprints, the Developers now spend every Friday morning with Paula for “story time” —their term for Product Backlog refinement. All Developers attend because each sees work through their own unique lens and has valuable input to the discussion. Because of these regular refinement sessions, Sprint Plannings have become more productive—and shorter. The Scrum Team now spends less time forecasting because the most important PBIs are “ready” and fresh in everyone’s minds. As the Product Backlog goes through seasons of increased or decreased churn, Product Backlog refinement can increase or decrease proportionally.

Scrum Artifacts

Scrum’s artifacts represent the work to be done in the product and the Sprint, as well as the work and value that have already been done within the product. Each artifact has a clear commitment and clear ownership. Each artifact is structured in a way that maximizes transparency of key information while providing opportunities for inspection and adaptation.

There are three artifacts in Scrum:

• ■   Product Backlog

• ■   Sprint Backlog

• ■   The Increment

The Scrum artifacts are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation. Each artifact also includes a commitment to ensure that it provides information that enhances transparency and focus against which progress can be measured. Table 1-10 lists the commitment for each Scrum artifact. These commitments exist to reinforce empiricism and the Scrum Values for the Scrum Team and their stakeholders.

TABLE 1-10 Scrum artifacts and related commitment.

Artifact	Commitment
Product Backlog	Product Goal
Sprint Backlog	Sprint Goal
The Increment	Definition of Done

Note Burndowns (product, release, Sprint, etc.)—as artifacts—were removed from the Scrum Guide in 2011. Their inclusion was considered too prescriptive. Although it’s important for the Scrum Team to monitor progress toward a goal, many practices could support this. Burndowns are certainly a popular option and are still acceptable and used by many Scrum Teams. No technique will replace the importance of empiricism. In complex environments, such as software development, what will happen is unknown. The Scrum Team can only use what has happened to influence its decision making.

Product Backlog

The Product Backlog is an ordered list of everything requested of the product. It is the single source of requirements for any potential changes to be made. Each item in the Product Backlog is called a Product Backlog item, or simply a PBI. A PBI can be a happy thing that doesn’t yet exist in the product, like a feature or an enhancement. PBIs can also be sad things, like a bug or defect to be fixed. PBIs can range from extremely important and urgent to silly and trivial. Because of this variety, I affectionately refer to the Product Backlog as a list of desirements. Fellow Professional Scrum Trainer Phil Japikse calls them requestaments. At some point, somebody, somewhere, for some reason desired or requested each item in the Product Backlog. Whether or not that item gets developed is a separate decision—one made by the Product Owner.

Note The Product Backlog is a dynamic, living document. It is never complete and will constantly change as desires change. The Product Backlog will exist as long as the product exists.

These types of items are considered valid PBIs:

• ■   User story

• ■   Epic

• ■   Feature

• ■   Enhancement

• ■   Behavior

• ■   Journey

• ■   Scenario

• ■   Use case

• ■   Bug/defect

These types of items are generally not considered valid PBIs:

• ■   Task (“refactor code,” “create acceptance tests,” etc.)

• ■   Acceptance criteria (“page content in German and English,” “report exportable as PDF,” etc.)

• ■   Acceptance tests

• ■   Nonfunctional requirements (such as “ticket search returns in less than 5 seconds”)

• ■   Definition of Done (“code is peer-reviewed,” “build pipeline exists,” “all tests pass,” etc.)

• ■   Impediment (“forgotten password,” “expired subscription,” “crashed hard drive,” etc.)

• ■   Anything else that doesn’t provide direct value to the users/stakeholders

Each PBI should be clearly identified by a title. This is the minimum amount of information required to add it to the Product Backlog. If the Product Owner is interested and decides it’s worth the time to describe it further, then a short description should be added. This description should be written in an easy-to-understand, business-friendly language. The PBI should also be assigned a business value. Once the Developers size it, it can be ordered with the other items in the Product Backlog. These conversations and sizing can be done during Product Backlog refinement or Sprint Planning. Table 1-11 lists the ways in which the Developers interact with the Product Backlog.

TABLE 1-11 Developer interactions with the Product Backlog.

Activity	When
Inspect it.	Any time.
Add a new PBI to it.	Any time (if allowed by the Product Owner).
Refine it (includes changing or removing PBIs).	Product Backlog refinement, Sprint Planning, or Sprint Review (with whole Scrum Team).
Reorder it.	Any time (if allowed/approved by the Product Owner).
Forecast work from it.	Sprint Planning (with whole Scrum Team) or any time during the Sprint after the forecast has been met and capacity allows.

I’m often asked if being responsible for the Product Backlog means that the Product Owner has to be the person who actually creates the PBIs (such as writing the user stories). The answer is no. The Product Owner can have a Developer or stakeholder (business analyst, customer, or user) create and even manage the PBIs. The Product Owner has the authority to update any item, such as making it more understandable, changing acceptance criteria, or removing any item deemed unnecessary.

A PBI represents a request from somebody. It can take any number of shapes or forms. A user story is quite popular for teams practicing agile software development. This is primarily because user stories are lightweight and not technical. User stories describe the ask from the customer’s or user’s perspective. It is not a requirements document or a technical specification, nor is it a communiqué between the requirements giver and the Scrum Team.

A user story represents a “what” that the product should do. A well-written user story description will explain who wants or who would benefit from the capability, as well as how and why it will be useful. In a single sentence, a user story description provides lots of context, as well as a value proposition. Even bug reports can be written in the form of a user story.

The most popular format of a user story description looks like this: As a (role), I want (something) so that (benefit). An example would be, “As a returning technician, I want the app to remember my credentials so that I don’t have to sign in each time.” Another example would be, “As a visitor to the Fabrikam Fiber website, I want to see a list of recent tweets so that I know that Fabrikam Fiber and its products are alive and well.” Anyone looking at either PBI instantly knows the context and value to the end user.

Tip Don’t put the user story description in the PBI’s title. I’ve seen teams do this and the cards and lists get very messy. Keep the description short—and the title even shorter.

Having a title and a short, meaningful description is a good start. To properly complete a user story, communication between the Scrum Team and knowledgeable stakeholders is required. A complete user story includes the three C’s: card, conversation, and confirmation. I’ll elaborate.

The card is already done at this point. You have written a title and the description (in user story format) on a sticky note, an index card, or a work item. This allows somebody to reference the user story during conversation, update it, estimate it, rank it, and so forth.

Next, the conversation takes place with the customers, users, or domain experts. This conversation is meant to exchange thoughts and opinions. It can take place at any time with the Product Owner, the stakeholders, and the Developers as needed. If the Developers are to be involved, it could take place at Product Backlog refinement, Sprint Planning, or Sprint Review. Conversations that yield examples, especially executable and testable examples, are preferred over formal documents and mock-ups.

Finally, the confirmation occurs. Here the user story’s acceptance criteria are agreed on and recorded. These criteria help determine when the PBI is done—when all criteria are met and, in accordance with the team’s Definition of Done, the PBI is done. If and when the PBI gets forecasted for a Sprint, the Developers will create the appropriate acceptance tests to validate the acceptance criteria.

Tip Don’t create tasks, tests, or code for a PBI before the Sprint in which it has been forecasted for development. Conditions can change rapidly, forcing a change to the PBI or its acceptance criteria. Time spent creating these kinds of artifacts ahead of time will often be wasted. The plan for developing a PBI, as well as any code or tests, should be created at the latest responsible moment—such as during the Sprint. Even though you will always know more tomorrow than today, you should avoid falling into the trap of doing things at the last possible moment. Besides, you have plenty of work in the Sprint Backlog without designing or coding ahead.

Whoever creates a PBI should be sure to INVEST in it. The mnemonic INVEST is a reminder of the characteristics of a good PBI:

• ■   I–Independent   As much as possible, the PBI should stand alone, without any dependency on another PBI. Try to create PBIs that don’t have long “dependency chains.”

• ■   N–Negotiable   The PBI can be changed and rewritten up until it gets forecasted, but significant changes after being forecasted should be avoided and minimized. Minor tweaks are okay as long as they don’t greatly affect the size that the Developers estimated.

• ■   V–Valuable   The PBI must deliver value to the user or the customer. This value is often delivered through a visible, tangible user interface, but not always.

• ■   E–Estimable   The Developers must be able to size the PBI. If too little is known, it will be difficult for them to have a meaningful conversation and come to any kind of shared understanding or consensus on size.

• ■   S–Small   The PBI must be small enough that the team can develop it—according to the Definition of Done—in a single Sprint and preferably within a few days. There are many suitable techniques for decomposing/splitting PBIs.

• ■   T–Testable   The acceptance criteria are clearly understood and can be tested. This is probably the most important characteristic. It relates to the third “C”—confirmation.

You can think of the Product Backlog as an iceberg, as shown in Figure 1-2. PBIs on the top, above the surface, are what the Developers have forecasted for the current Sprint. These items are very clear (denoted by a lighter color), sized small enough, and ready to be worked. Below the surface, the Product Owner knows what other PBIs they would like in the future, but it won’t be clear which ones surface until the next Sprint Planning. These items are generally understood and sized so that a release plan can be devised. These are the items that will be in scope during upcoming Product Backlog refinement sessions.

FIGURE 1-2 The Product Backlog iceberg.

Below the release, you will find all the other PBIs that may or may not make it into a future release. Some of these may have only a title or a vague description (denoted by darker colors) of the desired functionality. Some PBIs may even remain in these cold, chilly depths for eternity—or until they are deleted.

The Product Owner is accountable for managing the Product Backlog. This includes the clarity and precision of its contents. They should also ensure that the Product Backlog is visible to all interested parties. The Product Owner will order (prioritize) the PBIs to meet the Product Goal. The PBIs at the top of the ordered Product Backlog will, more than likely, be what the Developers work on next. The Product Goal should be discernible by studying the order and content of the PBIs. If necessary, the Scrum Master should coach the Product Owner on how to manage the Product Backlog more effectively.

Note Starting in 2011, the Scrum Guide began using the term “order“ instead of “prioritize.“ This subtle change has led to some confusion, which is why I typically use both terms together. For example, a Product Owner might urgently want to sell products and accept payments, but this capability requires a dependent shopping cart feature to be developed first. Although selling products and accepting payments is a higher priority, developing the shopping cart is of higher order—because of the dependency.

Creating an effective Product Backlog can be difficult. It can be time-consuming. It can become political. However, once you’ve gone through the exercise of creating the Product Backlog, you’ll wonder how you ever got along without one. Just having everything in one ordered list can be a game changer!

Fabrikam Fiber Case Study

Creating the initial Product Backlog was difficult. Requirements, feature requests, and bugs were tracked by different people in different formats. Giving up control of those lists started a turf war—but in the end, it was best for the product. When possible, PBIs were converted to a user story format. Today, the Scrum Team maintains its Product Backlog in Azure DevOps. The administrator gave permission to anyone on the Scrum Team to manage the Product Backlog. Everyone else can only view it. Paula (the Product Owner) is considering granting access to some additional stakeholders to help her create and manage PBIs.

Sprint Backlog

The Sprint Backlog contains the Sprint Goal, the PBIs forecasted to be developed during the Sprint, and the plan (for example, tasks or tests) for developing them, and the Sprint Goal. The Sprint Goal and forecasted PBIs were agreed on and selected through collaboration of the Scrum Team during Sprint Planning. The plan for developing them was agreed on through collaboration of the Developers. The Sprint Backlog is the output of the Sprint Planning and represents the Developers’ forecast of what functionality will be in the next software product Increment, the plan for how it will happen, and the Sprint Goal explaining why the Scrum Team is doing it.

The Developers own the Sprint Backlog—they are wholly responsible for how to implement the PBIs, as long as they do so in accordance with the Definition of Done. Nobody can tell the Developers how to develop the Increment. Nobody except the Developers themselves can add, edit, or remove items from the Sprint Backlog. The Sprint Backlog should be kept up to date and visible to the Developers. It provides a real-time picture of the work that they plan to accomplish during the Sprint. The Product Owner, the Scrum Master, and stakeholders don’t necessarily need access to the Sprint Backlog.

Tip Increasing the Sprint Backlog’s visibility beyond the Developers is an invitation for the three “M’s”: misunderstanding, meddling, and micromanaging. Allowing stakeholders, or any interested parties, to view the Product Backlog or burndown charts (if used) is preferable to seeing all of the technical and tactical details in the Sprint Backlog. In fact, even the Product Owner might want to stay out of the Sprint Backlog to avoid misunderstanding, meddling, and micromanaging.

Table 1-12 lists the ways in which the Developers interact with the Sprint Backlog.

TABLE 1-12 Developer interactions with the Sprint Backlog.

Activity	When
Inspect it.	Any time
Move a PBI from the Product Backlog into it.	Sprint Planning or any time afterward (with Product Owner collaboration)
Add, update, split, or remove a task or test in it.	Sprint Planning or any time afterward until Sprint Review
Take ownership of a new task or test in it.	Any time (as the plan demands)
Update status of a PBI, task, or test in it.	Any time (as status changes)
Estimate remaining work.	At least daily, if not more often

All Developers should collaborate on the plan and create the tasks or tests. Scrum Teams must be cross-functional for just this reason. Everyone can and should contribute. This will create a richer and more honest Sprint Backlog than if only one or two “specialists” create the plan. A good approach is to start with a conversation in order to understand the PBI and discuss any potential plan. The plan could have begun emerging weeks earlier at Product Backlog refinement. The plan can emerge onto sticky notes or a whiteboard, and then be transferred to a tool like Azure DevOps. There’s zero technical debt and waste in a discussion and close to zero in a set of sticky notes.

The Developers must do their best to identify all work in the Sprint Backlog, not just the design, coding, and testing items. There may be learning, installing, data entry, meetings, documentation, deployment, training, and other tasks. The Definition of Done might drive the creation of additional tasks for each PBI as well.

Tip Have the Definition of Done posted nearby during Sprint Planning. It will help the Developers as they brainstorm, forecast their work, and create the plan. Also, depending on how the last Sprint went, there may be additional work in the Sprint Backlog related to improvements identified at the Sprint Retrospective.

The Developers should estimate their Sprint Backlog items at least daily. This can be done before or after the Daily Scrum but preferably not during. Most teams I coach prefer to estimate work remaining before the Daily Scrum so that they will have accurate analytics to reference. Some high-performance Scrum Teams won’t bother tracking hours or estimating remaining work on tasks. They focus on the Sprint Goal and delivering the PBIs, not the tasks. It is more difficult to assess progress without this information, but it’s safe to assume that they’ve built a ton of trust with the Product Owner and stakeholders at that point.

Note Professional Scrum Teams don’t consider the time spent working on a task. Tracking actual hours is counterproductive to obtaining the Sprint Goal. I would even call it wasteful. If, however, an organization requires its employees to track their time to get paid or bill a client, that’s a separate discussion. The worry is that once such a metric is created, it would be used in a command and control way. For example, a manager might see that a set of UX design tasks took 28 hours and then use that as an estimate for future work, or as a stick to beat the Developer with if their next set of tasks goes beyond that number—which it could, because development in a complex space is very difficult and full of risk.

The Sprint Backlog will be empty at the start of a Sprint. It will begin to emerge during Sprint Planning, and (ideally) be populated with tasks by the first few days of the Sprint. Tasks can be identified all the way through the Sprint, but it is difficult to assess progress if you don’t know what the plan is. Even Professional Scrum Teams must change their plan sometimes. Each PBI introduces new complexities that can derail an execution plan. New tasks may have to be created mid-Sprint. This is not uncommon.

Tip In Scrum, work should never be directed or assigned. When creating a new Sprint Backlog task, don’t assign it to anyone. For example, you should resist the urge to assign the testing tasks to Toni (even though she has a background in testing). Doing so will decrease opportunity for other team members to collaborate and learn. When the time is right, the team should decide who will take on a task. The team will take many factors into account, including the background, experience, availability, and capacity of the Developer. I will spend more time on this topic in Chapter 8.

As the Scrum Team improves, it will learn to manage risk better by taking on riskier work early. The team will also become better at creating a plan and identifying the full spectrum of tasks, at least at a high level, during Sprint Planning. It’s okay for the more distant tasks to be coarsely defined. As the time nears for that piece of work to begin, the team can decompose and reestimate.

If Sprint burndown charts are being used, their trend lines will help predict when the Developers will be done with their work. Observers of the burndown charts need to understand that the Developers will know more tomorrow than they did today—so they should expect change. This means that the burndown may occasionally go flat or go up. The Scrum Master should be able to provide this education to anyone with questions.

Fabrikam Fiber Case Study

During Sprint Planning, the Developers brainstorm the plan for developing the Increment and achieving the Sprint Goal. When they were just starting out with Scrum, they would only get one or two PBIs planned out. They delayed the planning of the rest of the PBIs until later in the Sprint. Over time, they’ve improved in the way they decompose and plan their work, now being able to create most of the Sprint plan during Sprint Planning. Regular Product Backlog refinement has made Sprint Planning more efficient as well. The Developers still estimate tasks in hours but have made improvements in that process. Originally, they would have the “experts” in the various task areas do the estimates. That made estimation go quicker, but during development, they would usually blow their estimates because the expert wasn’t always the one who performed the work. They now estimate the tasks collaboratively. They also find that they are under as many times as they are over on their estimates. They can live with that.

The Increment

Scrum is an iterative and incremental product development framework. The word incremental means “occurring in especially small increments.” Each Sprint is an especially small period of time during which the team develops one of these small increments. These small periods of time (Sprints) reduce risk by maximizing collaboration and feedback. Incremental delivery of a Done product ensures that a useful version of the working product is always available.

An Increment is a concrete stepping-stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. In order to provide value, the Increment must be released.

Multiple Increments may, in fact, be created within a Sprint. The sum of the Increments is presented at the Sprint Review to support empiricism. An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. Work cannot be considered part of an Increment unless it meets the Definition of Done.

Tip If possible, make the Increment available to the Product Owner and stakeholders throughout the Sprint. Think of it as a hands-on demo. As the Developers finish a PBI, a demo environment is provisioned for people to inspect the product. This doesn’t have to be any kind of a formal testing, such as user acceptance testing (UAT) with formal testing agendas such as manual acceptance tests—just something that supports exploratory testing and encourages feedback during the Sprint. This is better than waiting until Sprint Review for feedback, especially from the Product Owner, and especially if they don’t like it!

Note The notion of the Increment being releasable means that it could be released (to the customer, to production, to the app store, etc.) if the Product Owner chooses to do so. This is possible because the Increment contains only Done PBIs. PBIs aren’t done until they meet the level of quality defined in the Definition of Done. The Product Owner may decide to wait until several related PBIs are completed (release by feature/scope), until a certain point in time (release by date), or as each PBI is done (continuously). Older Scrum Guides referred to the increment being potentially releasable—to stress the fact that it’s the Product Owner’s decision and doesn’t necessarily happen automatically.

Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a PBI meets the Definition of Done, an Increment is born. In other words, the Definition of Done creates transparency by providing everyone with a shared understanding of what work was completed as part of the Increment.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even inspected at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. If the Definition of Done for an Increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If no such standards exist, the Scrum Team must create a Definition of Done appropriate for the product. Once created, the Developers are required to conform to the Definition of Done.

Note If there are multiple Scrum Teams working together on a product, they must mutually define and adhere to a common Definition of Done. Individual Scrum Teams may choose to apply a more stringent Definition of Done within their own teams, but they cannot apply less rigorous criteria. I cover this topic in more detail in Chapter 11.

The Definition of Done is not a formal artifact in Scrum, but it might as well be. It is very important. It serves as the commitment for the Increment and, as a corollary, as a commitment to each PBI going into the Increment. In other words, Done is the state when a PBI has been developed according to team’s Definition of Done. Scaling that up, Done is also the state when the Increment containing all the done PBIs becomes Done and, thus, becomes releasable.

The Definition of Done is a simple, auditable checklist created by the Scrum Team. It may be based on organizational standards, product constraints, and Developer practices. The Definition of Done must be made transparent to the stakeholders, and they must understand its content and purpose. This is why it must be simple and explainable to stakeholders.

Here is a simple Definition of Done:

• ■   All acceptance criteria have been met.

• ■   A build pipeline exists.

• ■   No code analysis errors or warnings exist.

• ■   All new code is covered by unit tests.

• ■   All automated unit and acceptance tests pass.

• ■   A release note exists.

• ■   The Product Owner likes the work.

Definitions of Done can be quite long and complex. Everything in the definition should be achievable, although some items may not be applicable. For example, if the Developers are working on a PBI that is mostly graphic design–centric, there may not be any code to unit-test. For all PBIs that have code, however, the team must create unit tests.

The Definition of Done is there for a reason. The Developers should never cut corners by ignoring any part of it in order to complete the forecast. The team has already unanimously decided that quality, as defined in the Definition of Done, is more important than getting done more quickly.

Note The Definition of Done is a minimum standard. There may be times when the Scrum Team may want to do more than the minimum. This is acceptable as long as the extra effort is justified and not considered “gold plating.“ Gold plating is when one or more Developers continue to work on a PBI beyond what is necessary. This extra work is typically not worth the value that it adds to the product. When in doubt, check with the Product Owner before adding new functionality.

The Definition of Done should be inspected during the Sprint Retrospective. Over time it should increase, as the Scrum Team wishes to improve its quality practices. It’s a smell—and possibly a dysfunction—if a Definition of Done remains unchanged Sprint after Sprint.

Note In this book I will differentiate between done and Done. I will use lowercase done to simply mean finished with a task or piece of work. I will use uppercase Done to mean that the PBI or Increment is completed according to the Definition of Done.

Undone Work

An explicit and concrete Definition of Done may seem like a small piece of the development process, but it can be the most critical checkpoint during a Sprint. Without a consistent meaning of what Done means, Developers cannot have meaningful conversations with stakeholders, progress cannot be accurately assessed, planning will be impacted, and even the Increment’s value becomes questionable. Having a transparent Definition of Done—that the team adheres to—ensures that everyone knows the Increment produced at the end of Sprint is of high quality.

Professional Scrum Developers should not generate undone work. They should also make sure that “done” means Done. In the long run, it will be cheaper to hold fast to the Definition of Done by improving their practices than to keep sprinting with an unknown amount of work still to be finished at the end of the release. For example, I have worked with teams that will complete the design and coding Sprint after Sprint but accrue the testing work until the Sprints just before release. Don’t do this.

Note I will often ask organizational managers and decision makers which they value more: output or outcome. They always answer outcome. However, when I test them, their reflex is to value output instead. For example, let’s assume a Scrum Team has five Developers: three coding specialists, one testing specialist, and one operations specialist. If each works to capacity doing their specialty, they are maximizing output, but not necessarily getting anything Done. Lots of code gets written, but only some testing. If they collaborate and work outside of their specialties while they swarm or mob, they can complete more PBIs per Sprint, maximizing outcome. To the managers, however, it appears as though the team is slacking because they may not be “keeping busy to their capacity” or “doing the (specialty) job they were hired for.” This is an opportunity for the Scrum Master to coach the organization on this new, weird thing called Scrum and let them know that sometimes a team has to slow down to get more things Done! I cover this weird way of working in more detail in Chapter 8.

If the Product Owner looks at an Increment and doesn’t know how much work still needs to be done, they won’t really know when it will be ready to release. Any projections might be off . . . wildly. There may be a need for one or more “stabilization” Sprints—which are not a thing in Scrum—at the end of the release just to tackle all the accumulated undone work. If this occurs, conversations with stakeholders can become contentious.

What’s even worse is that the undone work from the Sprints accumulates exponentially, not linearly. Subsequent Sprints will require even more work to reach Done. This is due to a loss of context, code drift, and other factors. For example, 4 hours of undone work per Sprint for 6 Sprints won’t be 24 hours of work but could be more like 80 hours. This “undone work” uncertainty has no place in a framework that promotes transparency. Every effort should be made to eliminate undone work and so-called “testing,” “stabilization,” and “hardening” Sprints. The team should slow down, adhere to the Definition of Done, deliver more Done functionality, and realize more outcome. Output should never be the goal.

The Scrum Values

Successful use of Scrum depends on people becoming more proficient in living these five Scrum Values: Commitment, Focus, Openness, Respect, and Courage. I will explain these values and provide some examples in this section.

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect one another to be capable, independent people and are respected as such by the people with whom they work. The Scrum Team members have the courage to work on tough problems and do the right thing—even when nobody is watching.

These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life, building trust.

Table 1-13 lists some examples of how Developers can live the Scrum Values.

TABLE 1-13 Examples of how Developers can live the Scrum Values.

Scrum Value	Examples
Commitment	■   Committing to doing Scrum fully (according to the Scrum Guide) ■   Committing to collaborating, sharing, and learning ■   Committing to the achieving the Sprint Goal and delivering outcomes/value ■   Committing to continuous learning and improvement ■   Committing to adhering to the Definition of Done ■   Committing to the Scrum Values
Focus	■   Collaborating as a team to decide what to work on first ■   Creating a fit-for-purpose, Done increment without gold plating or technical debt ■   Collaborating as a team on a single PBI at a time (also known as swarming or mobbing) ■   Respecting the timebox to not overly plan, design, or develop ■   Respecting shared accountability to focus on overall outcome ■   Keeping the Product Goal or Sprint Goal in mind as work is planned/executed ■   Focusing on outcomes, not output
Openness	■   Being transparent about the team’s progress (or lack thereof) ■   Asking for help as well as offering help ■   Collaborating with other Developers, the Product Owner, and stakeholders ■   Sharing and hearing others’ perspectives ■   Admitting to being wrong and learning from mistakes ■   Being “teachable”
Respect	■   Acknowledging that people are naturally resourceful, creative, and capable ■   Accepting the diverse backgrounds, experiences, and range of skills ■   Knowing that people are motivated by autonomy, mastery, and purpose ■   Respecting the order of items in the Product Backlog ■   Assuming that people have good intentions and are doing their best ■   Listening, hearing, and acknowledging others’ opinions and perspectives
Courage	■   Being transparent about the team’s progress (or lack thereof) ■   Not releasing (or even showing) undone work to stakeholders ■   Able to say “I don’t know” and ask for help ■   To hold each other accountable for not meeting commitments ■   Admitting to being wrong, making mistakes, or making wrong assumptions ■   Sharing a dissenting opinion or engaging in productive conflict ■   Developing something that hasn’t been done before ■   Beginning development without having all of the “requirements” or details

This is just a partial list of ways that the Developers can live the Scrum Values on a daily basis. The rest of this book will list many complementary practices and associated ways to encourage the Scrum Values when applying those practices. Professional Scrum practitioners can quickly identify when the Scrum Values are being applied, encouraged, or hindered.

Professional Scrum

In this chapter I’ve described Scrum as it’s defined in the Scrum Guide. When a team begins practicing Scrum, they will select their own complementary practices (user stories, Fibonacci estimation, story mapping, acceptance test-driven development, etc.). This will result in that team having created their own process. In other words, Scrum + complementary practices = a team’s process. While custom-tailored to your team and organization, simply practicing mechanical Scrum like this is not enough. Ken Schwaber and Scrum.org offer something better: Professional Scrum. More than just a marketing term, Professional Scrum is a combination of several concepts and adherence to their principles.

Professional Scrum is defined as a combination of these elements:

• ■   Mechanical Scrum   Practicing Scrum according to the Scrum Guide

• ■   Continuously practicing empiricism   Relentlessly seeking improvement through regular inspection and adaptation and then being transparent about it

• ■   Continuously practicing the Scrum Values   Living the values of commitment, focus, openness, respect, and courage each day through interactions with individuals

• ■   Continuously practicing technical excellence   Uncovering better ways of working and developing the product and sharing those learnings with others on the Scrum Team

Note I will refer to “Professional Scrum” in this book hundreds of times. I will mention Professional Scrum Teams, Professional Scrum Developers, Professional Scrum Masters, Professional Scrum Product Owners, and Professional Scrum Trainers. I do this repeatedly to differentiate over simple mechanical Scrum or even “certified” Scrum—both of which tell me nothing about the individual’s or team’s relentless pursuit of empiricism and improvement.

The Professional Scrum Developer

The Scrum Guide does not provide guidance on how to develop a product. In fact, during the time between Sprint Planning and the Sprint Review, the guide is intentionally vague. Other than requiring a Daily Scrum and suggesting regular Product Backlog refinement, not much guidance is provided at all. In fact, the rules only state that a Daily Scrum should occur, taking no longer than 15 minutes.

So, what about the other 7 hours and 45 minutes of the day? What should the Developers be doing during that time? That’s the million-dollar question. I could simply say “it depends,” at which point, you would throw this book in the recycle bin. Well, the short answer is, they should do the right thing, even when nobody is looking, while constantly improving in all they do. In other words, they should be practicing Professional Scrum. There are many longer answers, but it will take me another 10 chapters to go through it. I hope you have an interest as well as some patience.

Remember that developing a complex product like software is a risky endeavor for both the Scrum Team and the stakeholders (the customer or users). The development process is a complex undertaking consisting of analyzing, designing, coding, testing, and deploying. More things can go wrong than right. Any small mistake or fault can lead to wasted effort—if you are lucky. Some mistakes can lead to outright damage. Professional Scrum Teams understand this, and they make sure their stakeholders understand this too. Ideally the stakeholders will share in these risks. This means that the stakeholders as well as the Scrum Team understand that they are both equally responsible for identifying and mitigating these risks, as well as sharing responsibility if a risk evolves into waste or a disaster of some sort.

Let’s drop the customer out of the discussion for a minute. Developers on a Scrum Team collectively own many things. They own their successes and failures, just as they collectively own the code, bugs, technical debt, and other issues. Professional Scrum Developers should learn to rely on their fellow team members and to trust them. They know that they must be resolute, forthright, transparent, and able to compromise in order to reach their goals.

When I’m meeting with a new team, I will often ask what they think the software developer’s job is. “To write code,” is the almost universal answer that I hear. Being a career developer myself, I used to give the same answer. As my understanding has evolved, this answer now irks me a bit. I believe that a better answer would be that a developer’s job is to provide value in the form of working product. This answer encapsulates the attributes of a Professional Scrum Developer, which I’ve listed in Table 1-14.

TABLE 1-14 Attributes of a Professional Scrum Developer.

Attribute	Attribute
Collaborates whenever possible	Isn’t hesitant to ask for help
Collectively owns all aspects of product development	Isn’t afraid to work outside of their comfort zone
Doesn’t know everything but is willing to learn	Knows that they are part of a team and that they have an equal voice
Doesn’t release undone work	Looks for and minimizes waste in their practices
Has a stake in the success of the product	Makes commitments to their team members and keeps them
Has the right and responsibility to maximize self-managing capabilities	Obeys the Definition of Done without generating technical debt
Is honest in their estimates, goals, and forecasts	Only does work that provides value to the product
Is more than just a coder or programmer	Plans realistic goals and then commits to achieving them
Is not a hobbyist, but a professional	Reflects the Scrum Values as they work
Is responsible for the quality of the product	Respects the Scrum Guide and follows it rules
Is transparent in what they do and how they do it	Says “no” when appropriate

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   Scrum Guide   The official definition of Scrum written by Ken Schwaber and Jeff Sutherland—the co-creators of Scrum. The Scrum Guide describes the Scrum framework and codifies the rules of Scrum. You should download it from www.scrum.org/scrumguides and read it now. Its updates will supersede any guidance I’ve provided in this chapter.

• ■   Empiricism   Asserts that knowledge comes from experience and decisions should be made based on what is observed and known. Inspection, adaptation, and transparency enable empiricism.

• ■   Developers   The individuals on the Scrum Team who do the work. The Developers are a cross-functional group, of typically three to nine professionals who develop the forecasted work during the Sprint. Developers are more than just coders/programmers. They also include testers, architects, database professionals, UI/UX designers, analysts, and IT professionals.

• ■   Product   A vehicle to deliver value to stakeholders. It has a clear boundary and a well-defined consumer, and achieves some measurable value. A Product could be a service, a physical product or something more abstract—like software.

• ■   Product Goal   Describes a future state of the product that can serve as a target for the Scrum Team to plan against. The Product Goal is evident in the Product Backlog.

• ■   Product Owner   Represents the voice of the stakeholder (user or customer) and is responsible for maximizing the value of the product and the work of the Developers.

• ■   Scrum Master   The Scrum Master is responsible for ensuring Scrum is understood and practiced correctly within the Scrum Team as well as the organization.

• ■   Stakeholders   Anyone interested in the successful development of the product. Stakeholders can be managers, executives, analysts, domain experts, attorneys, sponsors, members from other teams, customers, and users of the software.

• ■   Sprint   A fixed-length event of one month or less that contains the other Scrum events.

• ■   Sprint Planning   The first event in the Sprint where the work to be performed is forecasted, along with a plan for developing it, and a Sprint Goal describing why the work is being performed.

• ■   Daily Scrum   An opportunity for Developers to synchronize activities and create a plan for the next 24 hours.

• ■   Sprint Review   An opportunity for stakeholders to inspect the Done PBIs in the releasable Increment in order to provide feedback.

• ■   Sprint Retrospective   An opportunity for the Scrum Team to inspect its practices and adapt a plan for improvement in the next Sprint.

• ■   Product Backlog refinement   An opportunity for the Scrum Team to discuss upcoming PBIs in order to add detail and estimates to make them ready for Sprint Planning. Product Backlog refinement is optional but should take up no more than 10 percent of the capacity of the Developers.

• ■   Product Backlog   An artifact that contains an ordered list of everything that might be needed in the software product, including bugs or defects to fix. Items in the Product Backlog are called Product Backlog items (PBIs).

• ■   Sprint Backlog   An artifact that contains the forecasted PBIs, the plan for developing them, and the Sprint Goal describing why the Scrum Team is doing this work.

• ■   The Increment   An artifact representing the sum of all done PBIs during this and previous Sprints. An Increment serves as a concrete stepping-stone toward the Product Goal.

• ■   Definition of Done   A shared understanding of what it means for the Developers to be done with the development of an individual PBI and, as a corollary, the Increment itself.

• ■   Undone work   Any PBI that was started in a Sprint but not yet finished. The Developers should operate in a way to minimize undone work as it is considered waste.

• ■   Scrum Values   Commitment, focus, openness, respect, and courage. Successful use of Scrum depends on people becoming proficient in living the Scrum Values.

• ■   Mechanical Scrum   Simply following Scrum according to the Scrum Guide.

• ■   Technical excellence   Experimenting with and uncovering better ways of developing and sharing those learnings with others on the team.

• ■   Professional Scrum   Practicing mechanical Scrum but with a relentless and continuous application of empiricism, the Scrum Values, and technical excellence.

• ■   Professional Scrum Developer   A Developer who operates under the principles of Professional Scrum.