A summary of the Scrum Guide to assist studying.

Scrum Guide Summary.md

❌✋ Stop!

This summary is outdated!

It was written based on the 2017 version of the Scrum Guide and is pending update to reflect what is in the 2020 versions.

---

Scrum Guide summary

This is a compilation (aka: my study notes) of key points taken from the Scrum Guide by Jeff Sutherland and Ken Schwaber. The sections below are organised the same ways as in the guide.

Links for practicing

• https://www.scrum.org/open-assessments
• https://mlapshin.com/index.php/scrum-quizzes/

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 Gruide

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

Uses of Scrum

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

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

Essence of Scrum -> small team of people that is

• 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 optimise
Iterative + Incremental	Predictability 🔮 + Risk Control 🛡️

Scrum Pillars

Scrum Pillars 🏛️
👇👇👇
Empiricism Pillars 🏛️
👇👇👇
Transparency + Inspection + Adaptation

1. Transparency

Aspects of the process -> Visible to people responsible for the outcome

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 minimise 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
• Optimised
  • Flexibility
  • Creativity
  • Productivity

Scrum teams are
Self-organising	Choose how to accomplish their work. Not directed by outsiders.
Cross-functional	Team have all competences needed. No dependency of outsiders.

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

Deliver of "Done" product -> Potentially useful version

Product Owner

Responsible for maximising 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.
• Optimising value.
• Ensuring visible, transparent and clear.
• Ensure the Development Team understands items.

The Development Team may do the work above as per arranged.

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 organisation.

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-organising: No one tell 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 specialised 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 those outside of team to understand which interaction 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 prioritise to maximise value.
• Practicing agility.
• Facilitate events.

Service to the Development Team

Several ways, including:

• Coach self-organisation and cross-functionality.
• Help to create of high-value products.
• Removing impediments.
• Coach the team in organisations 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 an effective adoption of Scrum in the organisation.

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 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

✅ Sprint Planning	✅ Sprint Review
✅ Daily Scrum	✅ Sprint Retrospective

❌ The Sprint itself is an event, but just as a container for the others, not an inspect and adapt opportunity per se)

• Do it in dedicated meetings for this purpose where all Development Team is present.

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 development

Planning➡️Daily Scrums & Dev Work➡️Review➡️ Retrospective

During the sprint:

• 🚫 No changes that would endanger the Goal ⛳
• Quality does not decrease
• 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 💥

Cancelling 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
  • No longer make 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 team to keep it within the time-box

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

  • Product Owner discuss 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.
  • Entire Scrum Team collaborates to understand the work.
  • Development Team decides the number of items to be taken into the Sprint. Only it can assess what it can accomplish.
  • 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 in 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-organise 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.

Product Owner helps to clarify selected items and make trade-off. If Development team determines it has too little 🐜 or too much 🐘 work, renegotiate.

SPRINT BACKLOG = The Items + The Plan

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

• During planning and
• Throughout the Sprint

Sprint Goal

• 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 scope and goal.

Daily Scrum

• 15 minutes time-box. Regardless 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.
• Optimises 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.
• Optimises probability of meeting the goal ⛳
• Development Team understands how it intends to work together.
• Eliminates 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 meeting the goal?
2. What will I do today to help meeting 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 next things to be done to optimise 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 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.
• Development Team discusses what went well, problems, and how they were solved.
• Development Team presents the items "Done" and answer questions.
• Product Discuss the current state of the Product Backlog. Projects likely target and deliveries based on progress so far.
• Group collaborates on what are the most valuable things to do next.
• How the marketplace and use of product have changed.
• Budget, potential capabilities and marketplace.

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

Sprint Retrospective

• 3 hours for one month Sprint. Shorter event for shorter sprints.
• Formal opportunity for Inspection and Adaptation.
• Scrum Team inspect 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 organisational 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 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

• Artefacts represent Work or Value.
• Opportunity to Inspect and Adapt
• Designed to maximise transparency.

Product Backlog

• 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 note 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.

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 discretion.

Better clarity and details -> Better estimations

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 compare to 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 no 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 Team work.
• It belongs solely to the Development Team.

Continuous Improvement -> add 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.
• 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 throughly 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) 📊
• Step towards a Vision or Goal 🎯🏃

Artefact Transparency

Decisions to optimise value and control risk are based on the state of the artefacts.

• ☀️ Completely transparent -> Good decisions 👍
• 🌤️ Incompletely transparent -> Not so good decisions 💩

Scrum Master has to:

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

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

Definition of Done

Everyone must understand of what "Done" means.

• May vary per Scrum Team.
• 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 satisfies the Definition of Done.

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

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

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

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

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