Scrum Guide: Purpose and Definition

Purpose of the Scrum Guide

• Scrum was developed in the early 1990s to help people understand it.
• The first version of the Scrum Guide was written in 2010.
• The Scrum Guide defines Scrum, and each element has a purpose to maximize value and results.
• Changing Scrum's core design, omitting elements, or not following its rules can limit benefits and cover up problems.
• Scrum is used within an ever-growing complex world, Scrum is adopted in many domains beyond software.
• Scrum is built upon by developers, researchers, analysts, scientists, and specialists.
• Scrum is purposefully incomplete and defines parts to implement Scrum theory, the rules of Scrum guide relationships and interactions.

Scrum Definition

• Scrum helps people, teams, and organizations generate value through adaptive solutions for complex problems.
• At its core, Scrum requires a Scrum Master to foster an environment where the Product Owner orders work into a Product Backlog.
• The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
• The Scrum Team and stakeholders review results and adjust for the next Sprint, and this process is repeated.
• The Scrum framework is purposefully incomplete, defining only the parts required to implement Scrum theory.
• Scrum relies on the collective intelligence of its users, guiding relationships and interactions rather than providing detailed instructions.

Scrum Theory

• Scrum is founded on empiricism and lean thinking.
• Empiricism states knowledge comes from experience-based decisions, lean thinking reduces waste and emphasizes essentials.
• Scrum uses an iterative, incremental approach to increase predictability and control risk.
• Scrum brings together individuals with the skills and expertise to do the work and share or acquire new skills.
• Scrum combines four formal events within the Sprint for inspection and adaptation.
• Scrum implements the empirical Scrum pillars of transparency, inspection, and adaptation

Transparency

• The process and work must be visible to those performing and receiving it.
• Important decisions are based on the perceived state of its three formal artifacts.
• Lack of artifact transparency can decrease value and increase risk.
• Transparency enables inspection, but inspection without it is misleading and wasteful.

Inspection

• Scrum artifacts and progress toward goals must be frequently and diligently inspected.
• Inspection helps detect potentially undesirable variances or problems.
• Scrum provides cadence through its five events to aid inspection.
• Inspection enables adaptation.
• Inspection without adaptation is pointless.
• Scrum events are designed to provoke change.

Adaptation

• Adjustments must be made without delay if a process deviates from acceptable limits or the resulting product is unacceptable.
• Adaptation is difficult when people are not empowered or self-managing.
• A Scrum Team adapts the moment it learns anything new through inspection.

Scrum Values

• Successful Scrum implementation depends on proficiency in five values: commitment, focus, openness, respect, and courage.
• Scrum Teams commit to achieving goals and supporting each other.
• Their primary focus is on Sprint work to progress toward goals.
• Scrum Teams and stakeholders are open about work and challenges.
• Members respect each other as capable, independent individuals.
• The team has the courage to do what is right and tackle tough issues.
• These values direct the Scrum Team’s work, actions, and behavior, reinforcing the values in decisions and actions.
• Scrum Team members learn and explore the values through Scrum events and artifacts.
• Living these leads to empirical Scrum pillars of transparency, inspection, and adaptation, building trust.

Scrum Team

• Scrum’s fundamental unit is a small Scrum Team composed of one Scrum Master, one Product Owner, and Developers.
• Scrum teams have no sub-teams or hierarchies, rather it is a cohesive group of professionals focused on one Product Goal.
• Scrum Teams are cross-functional, meaning members have all necessary skills to create value each Sprint.
• These teams are self-managing as they decide who does what, when, and how.
• A Scrum Team is small enough to be nimble and large enough to complete significant work within a Sprint, typically with 10 or fewer people.
• Smaller teams generally communicate better and are more productive.
• Larger ones should reorganize into multiple cohesive Scrum Teams, each focused on the same product, Product Goal, Backlog, and Owner.
• The Scrum Team is responsible for all product-related activities, including stakeholder collaboration, verification, and experimentation.
• They are structured and empowered by the organization to manage their work.
• Sustainable pace improves focus and consistency.
• The entire Scrum Team is accountable for valuable, useful Increment every Sprint.
• Scrum defines three specific accountabilities within the Scrum Team: Developers, Product Owner, and Scrum Master.

Developers

• Developers are committed to creating any aspect of a usable Increment each Sprint.
• The specific skills needed will vary with the domain of work, Developers are accountable for the following:
• Creating a Sprint plan, known as the Sprint Backlog.
• Instilling quality by adhering to a Definition of Done.
• Adapting their plan each day toward the Sprint Goal.
• Holding each other accountable as professionals.

Product Owner

• The Product Owner maximizes the product value resulting from the Scrum Team's work.
• Task execution may vary widely across organizations, Scrum Teams, and individuals.
• They are also accountable for effective Product Backlog management.
• Accountabilities:
• Developing and explicitly communicating the Product Goal.
• Creating and communicating Product Backlog items.
• Ordering Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible, and understood.
• The Product Owner may delegate work but is still accountable.
• The organization must respect Product Owner decisions shown in the Product Backlog content, order, and inspectable Increment at Sprint Review.
• The Product Owner is a person, not a committee, and is able to represent different stakeholders' needs in the Product Backlog.
• Stakeholders can influence the Product Backlog by trying to convince the Product Owner.

Scrum Master

• The Scrum Master establishes Scrum as defined in the Scrum Guide.
• Establishing Scrum means helping everyone understand Scrum theory and practice within each team and the organization.
• They are accountable for the Scrum Team’s effectiveness and enables the Scrum Team to improve practices.
• Scrum Masters are leaders who serve the Scrum Team and the organization, by coaching on self-management and cross-functionality.
• This role helps the Scrum Team focus on high-value Increments that meet the Definition of Done.
• This also causes the removal of impediments to the Scrum Team’s progress.
• The Scrum Master helps by:
• Ensuring all Scrum events are positive, productive, and kept within the timebox.
• Helps find techniques for Product Goal definition and Product Backlog management..
• Helping the Scrum Team understand the need for clear, concise Product Backlog items.
• Helping establish empirical product planning for a complex environment.
• Facilitating stakeholder collaboration as needed.
• Leading, training, and coaching the organization in Scrum adoption.
• Planning and advising Scrum implementations within the organization.
• Helping employees and stakeholders understand and enact an empirical approach for complex work.
• Removing barriers between stakeholders and Scrum Teams.

Scrum Events

• The Sprint is a container for all other events.
• Each Scrum event is a chance to inspect and adapt Scrum artifacts to enable required transparency.
• Failure to follow events as prescribed results in missed chances to inspect and adapt.
• Events bring regularity to minimize non-Scrum meetings.
• Optimally, events are held at the same time and place to reduce complexity.

The Sprint

• Sprints are the heartbeat of Scrum, where ideas are turned into value.
• They are fixed-length events of one month or less to create consistency.
• A new Sprint starts immediately after the previous Sprint concludes.
• All work to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
• During the Sprint:
• No changes would endanger the Sprint Goal.
• Quality does not decrease.
• The Product Backlog is refined as needed.
• Scope may be clarified and renegotiated with the Product Owner as more is learned.
• Sprints enable predictability through inspection and adaptation toward a Product Goal monthly.
• Sprint horizons that are too long can invalidate the Sprint Goal, increase complexity and risk.
• Shorter Sprints generate more learning cycles and limit risk and effort to a smaller timeframe.
• Each Sprint is considered a short project.
• Practices to forecast progress, like burn-downs, burn-ups, or cumulative flows do not replace the importance of empiricism.
• In complex environments, only what has already happened informs forward-looking decision-making.
• A Sprint can be canceled if the Sprint Goal becomes obsolete, and only the Product Owner can cancel the Sprint.

Sprint Planning

• Sprint Planning initiates the Sprint by determining the work to be performed, created collaboratively by the entire Scrum Team.
• The Product Owner makes sure attendees are ready to discuss the most important Product Backlog items and how they map to the Product Goal.
• The Scrum Team may invite others to attend Sprint Planning and provide advice.
• Sprint Planning addresses:
• Topic One: Why is this Sprint valuable?
  • The Product Owner proposes how to increase product value and utility, and the Scrum Team defines a Sprint Goal.
  • The Sprint Goal communicates why the Sprint is valuable to stakeholders and must be finished before Planning completes.
• Topic Two: What can be Done this Sprint?
  • The Developers select items from the Product Backlog to include in the current Sprint.
  • The Scrum Team may refine these backlog items, which builds understanding and confidence.
  • Developers knowing their past performance, capacity, and Definition of Done increases confidence in their Sprint forecasts.
• Topic Three: How will the chosen work get done?
  • For each Product Backlog item selected, the Developers plan the work to create an Increment that meets the Definition of Done.
  • In practice the Product Backlog Items are often deconstructed into daily tasks.
  • How this is done is at the sole discretion of the Developers.
  • How to turn items into increments of value is not dictated by any person outside of the developers.
• The Sprint Backlog includes, the Sprint Goal, Backlog items, plus the plan for delivery.
• Sprint Planning is timeboxed to eight hours maximum for a one-month Sprint and shorter when the Sprint is shorter.

Daily Scrum

• The purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, adjusting work.
• The Daily Scrum is a 15-minute event for the Developers.
• To reduce complexity, it is held at the same time and place every working day of the Sprint.
• If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
• The Developers select structure and techniques, as long as the Daily Scrum focuses on Sprint Goal progress.
• Focusing on progress and produces an actionable plan for the next day of work creates focus and improves self-management.
• Daily Scrums improve communications, identify impediments, promote quick decision-making, and reduce or eliminate other meetings.
• Developers adjust their plan, and may meet throughout the day for more detailed discussions when adapting or re-planning the rest of their work.

Sprint Review

• The purpose is to inspect the Sprint outcome and determine future adaptations.
• The Key stakeholders learn of results toward the Product Goal.
• The Scrum Team and stakeholders review accomplishments and environmental changes during the Sprint.
• Attendees work together to determine what's next, and the Product Backlog may be adjusted to meet new opportunities.
• To avoid the event becoming a presentation, the Sprint Review is a working session.
• Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint and shorter when the Sprint is shorter.

Sprint Retrospective

• The purpose of planning ways to increase quality and effectiveness
• How the last Sprint went is viewed with regards to individuals, interactions, processes, tools, and their Definition of Done.
• Factors often vary with the domain of work.
• Assumptions that led to problems are identified and origins explored.
• The Scrum Team discusses successes, problems, and the proposed solutions.
• To improve effectiveness, the Scrum Team identifies changes, and impactful improvements are addressed immediately.
• Changes may be added to the Sprint Backlog for the next Sprint.
• Sprint Retrospective is timeboxed to three hours maximum for a one-month Sprint, shorter for shorter Sprints

Scrum Artifacts

• Scrum represents work or value and maximizes transparency of information, so everyone inspecting them has the same basis for adaptation.
• Each artifact contains a commitment to provide focus, progress, and transparency.
• 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 reinforce empiricism and Scrum values for the Scrum Team and stakeholders.

Product Backlog

• The Product Backlog is an organized list of what is needed to improve the product which is managed by the Product Owner.
• The Product Backlog is the single source of work the team uses, and items must be ready for selection in a Sprint Planning event.
• Items usually have transparency through refining activities such as breaking down larger Product Backlog Items into smaller, more precise items.
• Also adds detail, a description, order, and size.

Commitment: Product Goal

• The Product Goal describes a future product state, serving as a target against which the Scrum Team plans.
• The goal is in the Product Backlog.
• The "what" to fulfill the Product Goal emerges from the rest of the Product Backlog.
• A product is a vehicle to deliver value meaning it has a clear boundary, known stakeholders, and well-defined users or customers.
• A product could be a service, physical product, or something more abstract.
• The Scrum Team must fulfill (or abandon) the long-termProduct Goal one objective before taking on the next

Sprint Backlog

• The Sprint Backlog consists of the Sprint Goal (why), Product Backlog items for the Sprint (what), and a delivery plan for the Increment (how).
• It is a plan by and for the Developers.
• It is a highly visible, real-time picture that helps the Sprint Team develop daily
• The Sprint Backlog is updated throughout the Sprint as more is learned.
• Has enough detail that they can inspect their progress in the Daily Scrum.

Commitment: Sprint Goal

• The Sprint Goal is the single objective for the Sprint.
• Although the Sprint Goal is a commitment by its developers, the flexibility to achieve it also provides the flexibility in terms of the exact work needed to achieve it.
• The Sprint Goal leads to coherence, focus, and encourages collaboration rather than working on separate initiatives.
• The Sprint Goal is created during Sprint planning.
• As developers work, they keep the Sprint Goal as a guiding light.
• If the work is different, they collaborate with the product owner to adjust the scope of the sprint backlog, without affecting the Sprint Goal.

Increment

• Each Increment is additive to all prior Increments and verified
• It leads to all Increments working together can be a concrete stepping stone toward the Product Goal.
• It must be usable to provide value.
• Multiple Increments may be created within a sprint.
• The sum of the Increments is presented at the Sprint Review to support empiricism.
• An Increment may be delivered prior to the end of the Sprint.
• The Sprint Review should never be a gate to releasing value.
• Work not meeting the Definition of Done will not be considered Increment.

Commitment: 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.
• An Increment is born when a Product Backlog item meets the definition of done
• The Definition of Done creates transparency by providing an understanding of the work completed.
• Product Backlog that does not meet these requirements is sent back for future development.
• Scrum Teams must follow an increment's definition of done to the minimum to meet requirements.
• The Scrum Team must create a definition of done appropriate for the product if it is not standard.
• Developers must conform to the Definition of Done.
• If multiple Scrum Teams work together on a product, they must define and comply with the same Definition of Done

End Note

• Scrum is free and immutable when followed as outlined in the Guide.
• A partial adoption is possible, but the result is not Scrum, Scrum only exists entirely.
• Scrum can function as a container for other techniques, methodologies, and practices.