Scrum — The Leader’s Perspective

Are you leading Scrum Teams? Are you a leader in an organization that’s leveraging Scrum? Hopefully, you’ve read the Scrum Guide to gain an understanding of the framework your teams are using and to understand your role in it.

You probably feel a bit left out, though… The Scrum Guide doesn’t explicitly call out the role of the Leader, but successful implementation of Scrum definitely requires leadership.

The Scrum Guide describes the leadership required by the Product Owner, Scrum Master, and Developers.

In this article, we’ll talk about leadership outside the Scrum Team.

Update: This guidance has been published as a Scrum.org white paper - The Scrum Guide Companion for Leaders.

What Scrum Means for You as a Leader

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

From a leader’s perspective, Scrum is an approach that can be leveraged whenever the organization is facing a problem/opportunity in an environment that contains uncertainty around either what value looks like or how to create it, or both. The three key ideas in Scrum are:

• Empiricism — Constantly sensing what is going on using tight feedback loops and responding accordingly rather than sticking to a stale plan. This is the essence of agility — the combination of awareness of the situation with the flexibility to respond. Another way to look at this is that through different types of feedback loops Scrum helps us manage/control risks:

• We manage/control the risk that we’re taking the wrong steps to solve a problem / build a product by doing the work in small increments and stopping to reflect and adjust course on a frequent and scheduled basis.

• We manage/control the risk that we might be focusing on the wrong goal by constantly reflecting on the value of increments we’re creating, together with our stakeholders and ideally by actually trying to use what we’ve created, and having the ability to reflect upon our goals and adapt them.

• We manage/control the risk that the way we work isn’t ideal for the situation through continuous inspection and adaptation of the way we work.

• Self-management — As their organizations grow and scale, Leaders often feel growing stress as they become decision-making bottlenecks. Complex problems and environments require constant decision making since our original plans don’t survive contact with reality. Complex problems require the involvement of multiple disciplines and leaders find themselves coordinating the work of these multiple disciplines, adding even more to the dependency on leadership which eventually slows down innovation and progress no matter how hard the leader works. In Scrum we rely on multi-disciplinary self-managed teams that are able to make decisions and create value on their own, with minimal external dependencies and management guidance. To be clear, self-management isn’t anarchy. These teams are organized within constraints and are aligned to the mission set by leaders on behalf of the organization. We work towards self-management over time, as we nurture the competence and awareness needed for it.

• Continual Improvement — For both the problem we are solving and how we are solving it Scrum encourages teams to continually strive to improve. The artifacts and events provide the opportunity to improve.

Many organizations struggle to create an environment of Empiricism, Self-management, and Continual Improvement since it’s very different from traditional approaches of structuring work, managing teams, and getting stuff done. The Scrum Guide describes the responsibility for this Scrum-friendly environment as “Scrum requires a Scrum Master to foster (such) an environment…”. However, the reality is there are many challenges that require help from other leaders outside of the team. These leaders typically find themselves in the middle — trying to set up the conditions for success in an organizational culture and senior leadership that is often at odds.

Before applying Scrum a leader needs to determine where and how to apply Scrum in the organization. Here are some of the typical questions a Leader would ask:

• Focus — What work are we doing in the organization where it’s most worthwhile to implement Scrum?

• Problem Ownership — For each of these areas, who should own value identification and maximization? (This is called the Product Owner in Scrum)

• Team Structure — What’s the best way to organize into teams or teams of teams that will allow the team to focus? How can we create these teams in such a way that will enable them to self-manage and run an effective empirical process of learning and value creation?

• Human Resources — What in the way we are structured, staffed, and governed do we need to change to enable successful value creation with Scrum?

• Stakeholder Management — Who are the right stakeholders to inspect the results of every Sprint? How can we get them to engage with the team and give useful feedback?

• Culture — How can we create an environment where feedback is an opportunity to do better rather than a demonstration of a mistake (that often has further consequences)

Scrum is simple so you can quickly understand it. It is incomplete — it requires you complement it with context-specific practices and solutions. The basic rules of Scrum can provide some guidance for what to do and how to behave as a Leader but they will not give you hard and fast answers to all of the above questions. Many of the right answers will emerge over time as the your team/s gain experience using Scrum in your context and you have a chance to test out some different ways to address the challenges that emerge.

To reinforce this concept — Scrum encourages teams and organizations to find the minimum viable way of working, try it out, and adapt based on experience. The more frequently you can close this “learning loop” regarding how your organization operates, the faster you’ll converge towards an approach that is optimized for your needs and context. As the organization and its context changes and evolves, the continuous improvement learning loop will enable further adjustment. Some practices might become stale and irrelevant. Your process can benefit from periodical “decluttering” same like your closet and your kitchen drawers. (If a practice/policy doesn’t spark joy… thank it for its benefit so far and stop doing it…)

The leader’s number one responsibility is to provide clarity of what good means and to help ensure that the environment that the teams are working in supports the use of Scrum.

Scrum Theory and Values

As mentioned earlier, Scrum is founded on empiricism — transparency, inspection, and adaptation. Empiricism is only possible in certain cultures and contexts. Leaders have the role of creating and nurturing the culture and shaping the context.

• Focus -Are your teams able to focus on one important mission/goal? Do they have one clear set of priorities? They know when to say “No it doesn’t make sense to start this now, our plate is full”. If you’re a senior leader this starts at the portfolio level — being able to say “let’s focus on these key initiatives” and mainly “let’s NOT do these other things until we actually have the organizational capacity to deal with them” creates the culture where focus is possible. Ideally, Leaders make courageous choices and organize their teams around concrete Product Goals reflecting these choices.

• Openness — Leaders should have open discussions about whether their organization/ecosystem is conducive to Empiricism and Scrum as well as inspecting and adapting the cultural behaviors and standards that can be impediments to an effective Scrum culture. Are you able to tell your senior leader they are wrong? Are your people able to tell you you’re wrong? How open will the conversation be in the Sprint Review when leaders and teams get together to inspect an increment of work? Will teams open up to what’s really going on? Effective transparency and inspection require this openness.

• Commitment — Leaders commit to setting the Scrum Team up for success and supporting it through the removal of things that get in the way of flow and feedback loops. For example, an existing quarterly planning meeting requires a long detailed report which has no value for the Scrum Team. When this waste is raised the leader should work with the organization to remove the need for the Scrum Team to provide it.

• Courage — Leaders have the courage to do the right thing when it comes to setting Scrum Teams up for success and when working on tough organizational problems. They make choices and communicate them and the rationale behind them. This doesn’t mean always siding with Scrum or the Scrum Team or making the popular decision. It might mean decisions that will create some hardship for them and others in the short term but are the right decisions when taking the long view.

• Respect — Leaders understand and respect the Scrum Team roles. They work with these roles within the Scrum accountabilities. Because the Scrum Team accountabilities do not directly map to the organizations job titles and structures this may require the leader to help smooth out any disconnects. Leaders approach the different Scrum events with respect to the work being done, the opinions being shared, and the rules of the Scrum process.

Leaders should be open about the work, the challenges in the work, and the process/structural/transformational challenges. They should have the courage to share with other leaders and teams, in a transparent way, what the challenges are. They should be committed and focused on addressing these challenges. They should proceed with respect to the rules of the Scrum framework and the space the Scrum Team needs to thrive. Serving a Scrum Team requires a delicate balance. In some cases you need to teach/mentor. In other cases you need to let things be and actively do nothing. In some other cases you need to proactively work with the Scrum Team on the issue.

This provides an environment where leaders are demonstrating transparency and the values of Scrum and also by showing these challenges it provides an opportunity for others to provide insights and solutions.

In summary, The Scrum Values of Focus, Commitment, Courage, Openness, and Respect all correlate to an environment that enables Trust, Empiricism, and Self-Management that in turn support innovation and value creation.

Creating a culture that thrives upon the Scrum Values is a tough mission. A key issue is that inspecting and adapting the culture is hard when the culture isn’t very transparent. Scrum helps by making the culture and context painfully transparent. Leaders should pay close attention to the tensions that Scrum highlights between its empirical self-management approach and the current organizational culture.

Addressing these tensions becomes a key leadership role.

One additional way Leaders can communicate the importance of the Scrum Values is to start by applying the Scrum Values of Openness, Courage, Focus, Respect, and Commitment to their work and interactions with others — including but not limited to the Scrum Team. For example, when presented with an opportunity to be focused they should call out that they are following the value of ‘focus’ and then describe its use. By constantly re-enforcing the Scrum Values and providing context they become role models for the Scrum Teams.

There are some situations where Leadership teams become Scrum Teams — in these situations, this helps the leaders understand and model the Scrum behaviors and activities as well as helping them use Scrum to implement Scrum. Introducing Scrum is a complex problem which is a perfect context to use Scrum.

Each situation is different which requires Leaders to apply Scrum in a different way, however ultimately leaders are accountable for creating an environment where Scrum thrives and teams leverage empiricism and self-management to solve complex problems and create value.

Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.

Scrum defines some boundaries for the exercise of figuring out Scrum Teams. Scrum Teams have a certain effective size. A person should ideally be on one Scrum Team. Each Scrum Team should be committed towards one Product Goal.

While the Scrum Guide does not explicitly talk about anyone outside of the Scrum Team, Scrum assumes organizational leadership and support.

Leaders have the role of leading the process of creating and nurturing a portfolio of Scrum Teams that execute the organization’s strategy. They have to courageously choose which areas to focus on and set concrete Product Goals to organize the Scrum Teams around.

Leaders will need to bridge the gap between the current organizational capabilities and the strategic needs. They’ll need to have open conversations with the right people about the options and implications. They will have to apply some pragmatic choices while committing to working to close strategic gaps.

They need to learn about the different accountabilities on the Scrum Team, figure out how to map them to different roles and people in the organization, and model/support the behaviors that lead to success with Scrum.

Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Developers are not necessarily software developers. The Scrum Guide refers to Developers as anyone responsible for developing a valuable Increment. This can include business analysts, testers, marketers, project managers, or anyone else.

Leaders should figure out how to identify the right set of Developers that together have all the skills necessary to create and deliver valuable Increments towards the Product Goal.

When identifying Developers for Scrum Teams there are a number of tensions that will become evident. These tensions include:

• Creating a team that has enough skills to deliver value — Minimizing dependencies on people outside of the team while being small enough to have effective collaborations.

• Managing Specialists — Many organizations encourage and reward people who are specialists in a particular skill set or domain. A Scrum Team needs to be focused and include all the necessary skills to deliver value. Deciding where to put specialists is a key decision made by leaders.

• Managing ‘Resources’ — Scrum encourages organizations to think of people as people rather than resources and encourages stable teams. However many organizations apply the mindset of resource optimization and treat people as interchangeable parts. A Leader will have to spend time managing this disconnect.

• Dependency Management — There is never an ideal Scrum Team and it will always require help and support from other teams or service departments. The Leader’s job is to ensure that the right compromises are made and when presented with opportunities for improvement as the Scrum Team operates to be able to make changes.

Addressing these tensions will require some tough choices as well as the investment of time/money with a mid/long-term perspective.

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

Identifying the right Product Owner is a crucially important Scrum design decision that Leaders of the organization need to think through. As the Scrum Guide states “For Product Owners to succeed, the entire organization must respect their decisions”. That typically means a certain level of seniority. This must be balanced with the Product Owner having the time to focus on supporting the Scrum Team. Even if these “just right” Product Owners exist in the organization, the Leader might struggle to get them to be available and interested to become a Product Owner.

Product Owners should ideally be entrepreneurs caring deeply about the product and its customers (internal or external). If it’s hard to find a Product Owner it might be a signal to inspect whether the Scrum Team is organized around a real Product. Identifying Products (whether they are real Products or other valuable internal/external services) is a key leadership exercise. It is tempting to skip it and just organize Scrum Teams around the existing organizational structure rather than “rocking the boat”. Leaders that want to maximize the benefits they get from Scrum and Product Ownership have the courage and willingness to reflect openly on how their organizational structure aligns with their strategy and vision and are committed to organizing around products and value.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

“Scrum Masters are true leaders who serve the Scrum Team and the larger organization”

The effective Scrum Master combines a facilitator, coach, teacher, mentor, change agent, and impediment remover. Helping everyone means also being available to Leaders and Stakeholders.

In reality, we more often find Scrum Masters that act as scribes/secretaries/clerks for their teams, admins, project or people managers, heroes taking all the burden of delivery on their shoulders, or the Scrum police. They struggle to coach the organization and its leaders/stakeholders whether because of their abilities/experience or how they are perceived/positioned.

The Scrum Master role is a unique one that doesn’t map easily to current organizational structures or areas of expertise. Most environments and cultures struggle to cultivate effective Scrum Mastery or leaders who serve in general.

Leaders have the role of identifying effective Scrum Masters for their teams that would be respected and listened to at the team and organizational level as trusted advisors/partners.

The Scrum Master is accountable for the success of Scrum within the Scrum Team. That success relies on the right culture/environment which requires partnership with Leadership.

Leaders need to be open to feedback/coaching from about their behavior and their organizational choices. They need to commit to working with the Scrum Master on addressing systemic impediments that limit the team’s potential.

Leaders should consider the following when working with Scrum Masters:

• Career path — Scrum Master isn’t necessarily a career path. It’s an accountability that requires certain competency. Having said that, Leaders looking to find great Scrum Masters for their teams need to figure out as well as provide transparency to how being a Scrum Master would support people’s career growth.

• Reporting Structure — Setting the Scrum Master up for success means figuring out a reporting structure that enables the Scrum Master to be honest and open with minimal risk of repercussion. For example, If the Scrum Master reports to the Product Owner it might make it hard for them to be honest and open about their challenges. If they report to the same people as the Developers there might be a lack of understanding for their role. A Scrum Master that’s outside of the Scrum Team’s reporting structure coming in as either an internal or external “consultant” provides certain benefits but carries certain disadvantages as well. Finding the right reporting structure is difficult and depends on both the situation and the people in the role. Leaders apply empiricism to figure out this complex problem. This means trying out a certain pattern, inspecting its impact, and amplifying or pivoting away as needed. The fact that these “experiments” involve human beings makes them even more complex and sensitive.

• Measurement — By putting in place the right measures a leader can clearly define what outcomes they are looking for, but deciding the right measures is often difficult and can become political.

• Title — There is much debate in the industry as to what job title is held by a Scrum Master. The Scrum Guide describes Scrum Master as an accountability highlighting that the job title will depend on the organization. For many organizations, Agile Coach may be the right job title. Deciding on the job title helps set the scene for the role and helps with recruiting. But more important to the actual title is the reasoning for the title.

• Teams Supported — Depending on the maturity of the teams, the complexity of the problems they are solving or the constraints of the situation the Leader must decide on how many Scrum Teams the Scrum Master supports. Leaders in many cases face the tradeoff between having a few passionate and effective Scrum Masters covering multiple teams, versus having a Scrum Master for each team that is also a Developer on that team and sees Scrum Mastery as their secondary accountability. Again, no clear choices here, but aim to have Scrum Masters who are passionate about Scrum Mastery and see it a key part of their career journey.

• Employment Status — Each situation is different but making decisions about if the Scrum Master is better served as an external contractor, or an internal employee requires some level of thought and choice. Both approaches have merit. Think of the courage the Scrum Master might have to “speak to power”. The openness people in the organization and team would have to listen to their ideas. The commitment the Scrum Master would have to the team and the organization. The respect they would garner from the Product Owner, Developers, Leaders, Stakeholders. And how much they will be able to focus on helping the Team.

• Where Scrum Masters come from — Often organizations naturally think that Project Managers should be the place Scrum Masters are recruited from. Project Management is a different, somewhat overlapping set of skills that may or may not house good Scrum Masters. Leaders should understand the Scrum Master accountability and open a wide aperture to find the right people for the role wherever they are in the organization. Sometimes, the right Scrum Master for the job is found by looking at the mirror…

Whether the Leader chooses to be a Scrum Master or not, they should draw upon the accountabilities, skills, and stances of the Scrum Master. By doing this they can better serve the team and the larger organization.

Scrum Events

Leaders should understand and serve the Scrum Events. Serving their teams can mean participating in an event and providing feedback or creating the conditions for a successful event (without participating, or sometimes even BY not participating). Leaders also serve their teams and stakeholders by considering the whole suite of events that take place in the organization and sometimes consolidating/eliminating non-Scrum events.

The Sprint

This is the fundamental structure that all work is done within. Sprints enable predictability and empiricism. Leaders should help their teams balance the risk of a long Sprint Horizon with the overhead and stress of too-short Sprints. During the Sprint Leaders help protect the team from distractions.

Sprint Planning

Sprint Planning is where the Scrum Team collaboratively plans their Sprint based on priorities set by the Product Owner. The Scrum Team discusses 3 topics — Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done? The Scrum Team commits to a Sprint Goal and provides a Sprint Forecast.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

As Stakeholders, Leaders don’t usually participate in Sprint Planning (unless they are also members of the Scrum Team). They are welcome to work with the Product Owner to influence the direction of the Scrum Team while supporting the Product Owner’s vision and Product Goal before and after Sprint Planning.

Leaders use the transparency of the Sprint Goal and Sprint Backlog to gain an understanding of where the Scrum Team is focusing and what to expect to see in the Sprint Review. They should avoid diving into the details of the Sprint unless the Scrum Team asks for help. Often Leaders find it hard to leave the Scrum Team to work as they see fit and often ‘offer’ help. Help can be perceived as managing the Scrum Team, which ultimately will discourage self management.

The Sprint Plan is a forecast provided by the Scrum Team. There is a tendency to assume this commitment is then used to judge the Scrum Team. Leaders should avoid this, as the more complex the work the more uncertainty exists. The commitment is for the Scrum Team to do their best to deliver the Sprint Goal, or to learn if this goal is unachievable.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is a 15-minute event for the Developers of the Scrum Team … If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Leaders generally don’t participate in the Daily Scrum. Any participants that aren’t involved in the work of the Sprint are considered a distraction. The people doing the work should focus on the work and solving problems rather than providing status updates or posturing. Leaders should help the Scrum Team with removing impediments rising out of the Daily Scrum that require their involvement.

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The success of a Sprint Review is determined by who’s there and how they show up. Leaders can help the Scrum Team get the right people to the Sprint Review and coach stakeholders in what’s the effective way to behave in this very valuable opportunity to Inspect and Adapt the direction of the Scrum Team and the Product.

In some cases the Leader will also be a real stakeholder themselves and this can provide them with the key opportunity to inspect how the team is doing and engage with them directly. This is also an opportunity to demonstrate the values that Scrum encourages such as Openness and Respect.

Leaders have a role in making sure that Stakeholders understand the scope of their influence in the Sprint Review and the fact that it is a feedback meeting. The Product Owner might (or might not) adapt the Product Backlog based on the discussion in the Sprint Review.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

While the Leader doesn’t participate in the Sprint Retrospective they can serve the Scrum Team by helping them implement improvements that span beyond the Team’s scope of control or even owning such improvements. The Leader can create an environment of continuous improvement that will encourage the Scrum Team to invest in improving how they work.

The Leader’s role in the Scrum Events

The Leader’s role isn’t necessarily to be IN the Scrum Events. Their main role is to create the conditions for successful Scrum Events and to serve the team by being interested in the feedback and insights generated.

• Leaders enable the team to have a Sprint Planning event in which they are empowered to figure out a realistic and sustainable Sprint Goal. They gain an understanding of direction via the Sprint Goal. This enables them to communicate with other stakeholders about the work of the team. (as they might be expected to do).

• Leaders don’t participate in Daily Scrum and don’t need to actively inquire about what takes place in them either. The Scrum Team will reach out to the Leader if there’s an impediment that requires their involvement.

• Leaders can participate in the Sprint Review as a Stakeholder, gain visibility to where the Product is based on the Increment, and provide feedback that will be considered by the Team and the Product Owner (but not necessarily adopted as such). They have an even bigger role in enabling an effective Sprint Review by working with other stakeholders to create an environment of empiricism and respect/self-management.

• Leaders serve their teams by helping them implement improvements that span beyond the team’s scope of control. They might take ownership of such improvements. They create the cultural conditions where continuous improvement work is a first-class citizen in the organization’s work plans and capacity allocations.

Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize the transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

• For the Product Backlog, it is the Product Goal.

• For the Sprint Backlog, it is the Sprint Goal.

• For the Increment, it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Leaders use the Scrum Artifacts as a window into the work of the Scrum Team. This transparency enables inspection and adaptation at the appropriate level while enabling the team to self-manage.

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Leaders respect the accountability of the Product Owner for the Product Backlog. The Product Owner will work with Leaders as stakeholders. They will make sure the Product Backlog is available and clear. The Product Owner and Scrum Team will be open to ideas from Leaders and other Stakeholders and will also have the courage to remain focused.

Commitment: Product Goal

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 in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Scrum Teams are formed to execute the organization’s strategic decisions. Each Scrum Team’s Product Goal is a key mechanism to ensure this strategic alignment. Leaders are responsible for ensuring that the right conversations take place between Scrum Teams and their strategic stakeholders around the progress made towards the Product Goal and its relevance. Agility at a strategic level relies on the ability to inspect and adapt Product Goals and adjust course as needed.

Sprint Backlog

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

The Sprint Backlog should not be used as a mechanism to control/manage the Developers on the Scrum Team or as a status reporting dashboard.

Leaders should respect the Developers ownership of the Sprint Backlog and give them space to self-manage their work within the Sprint. They should avoid treating the Sprint Plan as a tool to manage the Scrum Team. The plan is for the Scrum Team and enables leaders to provide feedback.

Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Leaders can use the Sprint Goal as a window towards the Scrum Team’s focus and commitment for the Sprint and should help the team achieve their Sprint Goal if the team reaches out for help.

Increment

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. In order to provide value, the Increment must be usable.

The ultimate accountability of the Scrum Team is to make incremental progress towards the Product Goal or to learn that is not possible and either reframe the Product Goal or focus on something else. Leaders need to work with the Scrum Team to help them make progress often in spite of the environment that they are working within. They need to support the Scrum Team to work within the technical and procedural and cultural confines of the organization.

Commitment: Definition of Done

The Definition of Done is a formal description of the state of each Sprint Increment when it meets the quality measures required for the product.

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 it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

The Definition Of Done makes what it means to be done transparent. It provides a mechanism to clearly communicate what it means to make progress, incrementally towards the Product Goal and therefore deliver value. It often provides a great way for the Scrum Team to set expectations with external groups. Leaders work with Scrum Teams to create and improve appropriate Definition of Done standards for the organization. Improving the organizations’ Definition of Done is a mechanism Leaders can leverage to raise the level of quality, professionalism, and transparency while letting the Scrum Team/s self-manage. Leaders provide support for Scrum Teams that are striving to achieve a more complete Definition of Done.

This guidance has been published as a Scrum.org white paper - The Scrum Guide Companion for Leaders.

missing-image-placeholder

Scrum works best when it’s connected to real business outcomes, not just ceremonies. Explore advisory and coaching or let’s talk.