Summary of the Scrum guide to ensure you pass the exam

This is a compilation of key points taken from the Scrum Guide by Jeff Sutherland and Ken Schwaber. The sections below are organized the same way as in the guide.

Purpose of the Scrum Guide

Scrum guide is the definition of the Scrum Framework.

Definition of Scrum

• ❌ not a process
• ❌ not a technique
• ❌ not a method
• ✅ Scrum is a framework
  • Lightweight
  • Understanding = simple
  • Mastering = difficult

Managing work on complex adaptive problems

Delivering products of the highest possible value

• Productively
• Creatively

Continuously improve

• Product
• Team
• Environment

Consists of

3 Roles	Product Owner Scrum Master Development Team
5 Events	Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective
3 Artifacts	Product Backlog Sprint Backlog Product Increment
Bound together by Rules	The Scrum Guide

Backlog Refinement is not a formal event. It is a constant practice that may be organized as a team event.

Uses of Scrum

• Research
• Develop products
• Release products
• Operational environments
• Renew products

Scrum has been used to develop almost everything we use in our daily lives.

Essence of Scrum -> a small team of people that are

• Flexible
• Adaptive

In the Scrum Guide, the word DEVELOPMENT refers to complex work.

Scrum Theory

Scrum is founded on empirical process control theory. Also known as Empiricism:

• Knowledge comes from experience
• Make decisions based on what is known

Scrum approach is	In order to optimize
Iterative + Incremental	Predictability + Risk Control

Scrum Pillars

1. Transparency

Observers share a common understanding of what they see. Example:

• Common language
• Common Definition of “Done”

2. Inspection

What:

• Artifacts
• Progress towards Sprint Goal

When:

• Frequently
• Not so frequent that it gets in the way of work

Who:

• Skilled inspectors

Where:

• At the point of work

3. Adaptation

If the skilled inspector finds out that aspects deviate out of acceptable limits:

• Process or material must be adjusted
• Do it ASAP  -> to minimize further deviation

Inspection and Adaptation -> 4 formal events

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective

Scrum Values

Commitment People personally commit to achieving the goal
Courage Courage to do the right thing and work on tough problems
Focus Focus on the work and goals
Openness Be open about work and challenges
Respect Respect people to be capable and independent

The Scrum Team

• Product Owner + Development Team + Scrum Master
• Increasingly effective
• Optimized
  • Flexibility
  • Creativity
  • Productivity

Scrum teams are
Self-organizing	Choose how to accomplish their work. Not directed by outsiders.
Cross-functional	The team has all competencies needed. No dependency on outsiders.

The team delivers iteratively and incrementally -> Maximized opportunities for feedback

Deliver of “Done” product -> Potentially useful version

Product Owner

Responsible for maximizing the value of the work done by the Development Team.

Is 1 single person. May represent the desires of a group/committee.

Owns and manage the Product Backlog, including:

• Expressing items clearly.
• Ordering items.
• Optimizing value.
• Ensuring visible, transparent, and clear.
• Ensure the Development Team understands items.

The Development Team may do the work above as arranged.

The Product Owner is solely accountable for the Product Backlog. He owns it.

Anyone who wants to change Product Backlog priorities must address the Product Owner.

PO decisions are:

• Visible in items’ content and ordering.
• Respected by the organization.

No one can force the Development Team to work on something else.

Development Team

Professionals who deliver a potentially releasable Increment of “Done” product at the end of each Sprint (required for the Sprint Review).

• Manage their own work.
• Self-organizing: No one tells them how to turn Product Backlog items into Increments.
• Cross-functional: as a team, have all skills necessary to create the Increment.
• There are no titles.
• There are no sub-teams.
• Members may have specialized skills, but accountability belongs to the team as a whole.

Development Team Size

3 to 9 people.

Small enough to remain nimble.

Large enough to complete significant work in a Sprint.

Ninble (adj): quick and light in movement; moving with ease; agile; active; rapid:

Size	Consideration
❌ 2	Decreased interaction, smaller gains. Skill constraints
✅ 3 – 9	Optimal. SM and PO not counted (unless they are also executing work in the Product Backlog).
❌ 10 or more	Requires too much coordination. Too much complexity for empiricism to be useful.

Scrum Master

Promote and support Scrum as defined in the Scrum Guide.

Help that outside of the team to understand which interactions are helpful and which aren’t.

Is a servant-leader.

Service to the Product Owner

Several ways, including:

• Ensure goals, scope, and product domain are understood.
• Find techniques for Backlog management.
• Create awareness for clear and concise Product Backlog items.
• Understanding the product planning empirically.
• Help to understand how to prioritize to maximize value.
• Practicing agility.
• Facilitate events.

Service to the Development Team

Several ways, including:

• Coach self-organization and cross-functionality.
• Help to create high-value products.
• Removing impediments.
• Coach the team in organizations and environments that don’t adopt/understand Scrum.
• Facilitate events.

Service to the Organisation

Several ways, including:

• Lead and coach Scrum adoption.
• Plan implementation.
• Help people to understand and use Scrum and empiricism.
• Cause changes to increase productivity.
• Work with other Scrum Masters for effective adoption of Scrum in the organization.

Scrum Events

The 5 Events

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
5. Sprint

• Create regularity
• Minimize the need for other meetings
• Time-boxed = maximum duration
  • End when the timebox expires
  • End earlier if the purpose of the event was achieved
  • Ensure an appropriate amount of time spent
  • Avoid waste
• Designed for critical transparency and inspection

Refinement (aka Grooming) is not a formal event. It is a practice that can be tackled as one

Opportunities to Inspect and Adapt

The Sprint

The container event.

• One month or less
• Starts immediately after the previous one
• Create a Product Increment
  • “Done”
  • Usable
  • Potentially releasable
• Length doesn’t change after it starts
• Consistent duration throughout the development

During the sprint:

• No changes that would endanger the Goal
• Quality does not decrease
• The scope may be clarified and renegotiated as more is learned
  • Negotiation = Development Team + Product Owner

Each Sprint =~ project no longer than 1 month long.

• Accomplish something
• Has a goal of what to build
• Has a design
• Flexible plan
• Result = Product Increment

Size of the Sprint

Size	Consideration
✅ up to 1 month	Optimal, because: Limit risk to one month of cost Monthly inspection and adaptation Predictability
❌ longer than 1 month	Definition of what to build may change More complexity More risk

Canceling a sprint

Only the Product Owner can cancel before the time-box is over. May do under the influence of Stakeholders, Development Team, or Product Owner.

• If the sprint goal becomes obsolete
  • Company changes direction
  • Market changes
  • Technology changes
  • It no longer makes sense given the circumstances
• Very uncommon (rarely makes sense for short sprints)
• It consumes resources
• It is traumatic for the team

What happens on Sprint cancellation

• “Done” items
  • Reviewed
  • Potentially releasable are typically accepted by the Product Owner
• Incomplete work
  • Re-estimated
  • Put back into the Product Backlog
• Regroup for new Sprint Planning

Sprint Planning

Maximum of 8 hours for a one-month Sprint. Shorter event for shorter sprints. For planning the work to be performed during the Sprint.

It answers:

• What can be delivered?
• How will work be achieved?

Sprint Planning and Sprint Goal = Collaborative work of the Scrum Team (Development Team, Product Owner, Scrum Master)

Scrum Master is responsible to ensure:

• It happens
• Attendants understand the purpose
• Teach the team to keep it within the time-box

The Development Team may invite others to attend to provide technical or domain advice.

Product Owner ensures items are clear

Inputs	Output
Product Backlog Latest increment Projected capacity Past performance	Items selected Sprint Goal Plan to deliver

It is a 2 phases event (called “Topics”).

• Topic One: WHAT can be done this Sprint? – The Items

  • The Product Owner discusses the objective the Sprint should achieve and present items that, if completed, would achieve the Sprint Goal.
    • Work may be of varying size/estimated effort.
  • The entire Scrum Team collaborates to understand the work.
  • The Development Team decides the number of items to be taken into the Sprint. Only it can assess what it can accomplish.
  • The Development Team forecasts the functionality that will be developed.
  • Scrum Team crafts a Sprint Goal

The goal provides guidance to the Development Team on why it is building the Increment.

• Topic Two: HOW work will get done? – The Plan

  • At this point, Sprint Goal is set and items are selected.
  • How to build the functionality into a “Done” Product Increment
  • Work planned for the first days is decomposed into units of one day or less.

By the end of Sprint Planning, the Development Team should be able to explain how it intends to self-organize to accomplish the Goal and deliver the Increment.

Enough work is planned for the Development Team to be able to forecast what it believes it can do.

The Product Owner helps to clarify selected items and make trade-offs. If the Development Team determines it has too little or too much work, renegotiate.

SPRINT BACKLOG = The Items + The Plan

Development Team self-organizes to undertake (commit) the work in the Sprint Backlog

• During planning and
• Throughout the Sprint

Sprint Goal

• The objective for the Sprint.
• Created during Sprint Planning, by the Scrum Team (Development Team, Product Owner, Scrum Master).
• Can be met through the implementation of the Product Backlog.
• Provide guidance to the Development Team on WHY building the Increment.
• Causes the Development Team to work together (rather than on different initiatives).
• Kept in mind as the Development Team works.
  • However, if the work turns out to be different, Development Team and Product Owner renegotiate the scope and goal.

Daily Scrum

• 15 minutes time-box. Regardless of team size or Sprint length.
• Internal meeting for the Development Team (others must not disturb).
• Every day.
• Same place, same time = reduced complexity.
• Plan for the next 24 hours – no status reporting.
• Optimizes collaboration and performance.
• Key Inspect and Adapt meeting.
• Inspect
  • Work since last Daily Scrum (and forecast upcoming work).
  • Progress towards goal.
  • How progress is trending.
• Optimizes probability of meeting the goal
• The Development Team understands how it intends to work together.
• Eliminates the need for other meetings (they are still allowed though).
• Identify impediments.
• Decision-making.
• Track the sum of total work remaining for the Sprint.

The structure is set by the Development Team, it can be conducted in different ways.

The three questions model is only a suggestion:

1. What did I do yesterday to help meet the goal?
2. What will I do today to help meet the goal?
3. Do I see impediments that will prevent meeting the goal?

People from the Development Team often meet immediately after the Daily Scrum to

• Discuss details
• Adapt the plan
• Replan

Participants

Who	Responsibility
Scrum Master	Ensure the Daily Scrum happens. Teach time-boxing. Only allowed to participate if agreed by the Development Team. Ensure others out of the Development Team will not disturb.
Development Team	Owner of the meeting. Choose the format. Only mandatory and allowed participants, others must be invited.
Product Owner	Only allowed to participate if agreed by the Development Team. Doesn’t tell people what to do.

Sprint Review

• 4 hours for one month Sprint. Shorter event for shorter sprints.
• End of Sprint (before Retrospective).
• What was done in the Sprint?
• Inspect the Product Increment.
• Adapt the Product Backlog.
• Scrum Team + Stakeholders.
• Collaborate on the next things to be done to optimize value.
• Not a status meeting.
• Feedback and collaboration.
• It creates a valuable input for the next Sprint Planning.

Scrum Master is responsible to ensure:

• It happens
• Attendants understand the purpose
• Teach the team to keep it within the time-box

Elements included in a Sprint Review

• Scrum Team + key stakeholders invited by the Product Owner
• Product Owner explains items that were “Done” and not.
• The Development Team discusses what went well, problems, and how they were solved.
• The Development Team presents the items “Done” and answer questions.
• Product Discuss the current state of the Product Backlog. Projects likely target deliveries based on progress so far.
• Group collaborates on what are the most valuable things to do next.
• How the marketplace and use of products have changed.
• Budget, potential capabilities, and marketplace.

Outcome: revised Product Backlog that defines probable items for the next Sprint

Sprint Retrospective

• 3 hours for one month Sprint. Shorter event for shorter sprints.
• Formal opportunity for Inspection and Adaptation.
• Scrum Team inspects itself.
• Plan improvements to do next Sprint.
• Make next Sprint more effective and enjoyable.
• Plan how to increase product quality.
• Adapt the Definition of Done if
  • Necessary.
  • Appropriate.
  • Not in conflict with organizational standards.

Scrum Master is responsible to ensure:

• It is positive
• It is productive
• It happens
• Attendants understand the purpose
• Encouraging the team to improve within the Scrum process

Purpose:

• Inspect how last Sprint went
  • People
  • Relationships
  • Process
  • Tools
• Identify major items that went well
• Identify potential improvements
• Plan how to implement improvements

Outcome: Improvements to implement during the next Sprint (adaptation of the process).

Add to the Sprint Backlog(*) at least one high priority improvement identified in the last Sprint Retrospective.

(*) Not to the Product Backlog

Scrum Artefacts

• Artifacts represent Work or Value.
• Opportunity to Inspect and Adapt
• Designed to maximize transparency.

Product Backlog

• An ordered list of everything needed in the product.
• It is the single source of requirements.
• Belongs solely to the Product Owner, which is responsible for
  • Content
  • Availability
  • Ordering
• It is never complete.
• Evolves together with the product and environment.
• There is one Product Backlog for each Product.
  • A Product does not exist without one.
• It is dynamic, constantly changes, for a product that is:
  • Appropriate;
  • Competitive and
  • Useful.
• Grows constantly – it is a living artifact.
• One Product Backlog can be tackled by multiple teams.
• Upcoming work for the product.
• Items on the top are more clear and detailed. Lower the order, less detail.

The earliest development of Product Backlog	➡️	Initially known and best-understood requirements
Changes in business requirements, market conditions or technology	➡️	Changes in the Product Backlog

 

Product Backlog	Items
Features Functions Requirements Enhancements Fixes	Description Order Estimated Value Test description (that will prove completeness)

Product Backlog Refinement

• Scrum Team decides how and when, but not taking more than 10% of the capacity.
• Act of adding detail, estimates, and order to items.
• Ongoing process.
• Items can be updated at any time
  • By the Product Owner or
  • At the Product Owner’s discretion.

Better clarity and details -> Better estimations

The development Team is responsible for all estimates.

• Product Owner may help to understand items and make trade-offs, but
• The people who will perform the work have the final say on the estimate.

Monitoring Process Toward Goals

• At any point in time, the work remaining can be summed.
• Product Owner tracks the total remaining at the end of Sprint and compares it to the previous one.

Projective practices for trending suggestions
Burn-down chart	Work remaining in the Sprint
Burn-up chart	Projection of likelihood for delivering further features
Cumulative flow	Identify project constraints (bottlenecks)

These do not replace the importance of empiricism = what will happen is unknown and only what already happened may be used for decision-making.

Sprint Backlog

• Product Backlog items selected for the Sprint, plus a plan for delivering them = forecast by the Development Team about:
  • What functionality will be in the next increment and
  • Work needed to deliver it as a “Done” increment
• Makes visible the work necessary to deliver the Sprint Goal.
• It is a highly visible real-time picture of the Development Teamwork.
• It belongs solely to the Development Team.

Continuous Improvement -> adds to the Sprint Backlog(*) at least one high priority improvement identified in the last Sprint Retrospective.

(*) Not to the Product Backlog

Changes in the Sprint Backlog progress can be understood in the Daily Scrum.

Only the Development Team modifies the Sprint Backlog during the Sprint:

• New work required -> Added to the Sprint Backlog.
• Work performed -> Sprint Backlog updated.
• Work completed -> Estimated remaining work updated.
• Item identified as unnecessary -> Removed.
• The scope may be clarified and renegotiated as more is learned
  • Negotiation = Development Team + Product Owner

Monitoring Sprint Progress

At any point in time, the remaining work of the Sprint can be summed.

The Development Team tracks the total work remaining every Daily Scrum and projects the likelihood of achieving the Sprint Goal.

Tracking the total work remaining, the Development Team can manage its own progress.

Increment

The Product Increment is:

Sum of items completed during this Sprint	➕ plus	Value of increments from previous Sprints

Each increment is additive to the previous ones and thoroughly tested, ensuring all increments work together.

• “Done” at the end of the Sprint:
  • Useable conditions
  • Meet Scrum Team’s “Definition of Done”
  • Inspectable
• Supports empiricism (governed by metrics)
• A step towards a Vision or Goal

Artifact Transparency

Decisions to optimize value and control risk are based on the state of the artifacts.

• Completely transparent -> Good decisions
• Incompletely transparent -> Not so good decisions

Scrum Master has to:

• Ensure artifacts are completely transparent.
• Work together with Development Team, Product Owner, and others to understand if it is.
• Help to apply appropriate practices to fix transparency.
• Detect incomplete transparency:
  • Inspect artifacts
  • Sense patterns
  • Listen to what people say
  • Detect differences between expected and real results.
• Increase transparency of artifacts.
  • Learning, convincing, and changing.

Transparency is a path (doesn’t occur overnight).

Definition of Done

Everyone must understand what “Done” means.

• May vary per Scrum Team.
• A shared understanding of what means for work to be complete.
• Ensure transparency.

It guides the Development Team on knowing how many items it can select during Sprint Planning.

Purpose of Sprints = To deliver Increments of potentially releasable functionalities that satisfy the Definition of Done.

Does the organization have a minimum set of standards/development guidelines/conventions?

• YES -> Included as part of the Definition of Done (as a minimum).

• NO -> Scrum Team must define an appropriate Definition of Done.

• Multiple teams working on the same product -> Development Teams on all Scrum Teams chose a mutual Definition of Done.

As Scrum Team matures, the Definition of Done evolves to higher quality and may uncover work to be done in previously “Done” increments.