-
SCRUM
- a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems
- Scrum is simple
- Scrum wraps around existing practices or renders them unnecessary
-
Scrum requires a Scrum Master to foster an environment where
- 1. A Product Owner orders the work for a complex problem into a Product Backlog.
- 2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- 3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- 4. Repeat
-
SCRUM THEORY
-
Scrum is founded on empiricism and lean thinking
- Empiricism asserts that knowledge comes from experience and making decisions based on what is observed
- Lean thinking reduces waste and focuses on the essentials
-
Scrum pillars
-
Transparency
-
low transparency
- decisions that diminish value
- increase risk
-
Inspection
- frequently
- to detect potentially undesirable variances or problems
- Scrum events are designed to provoke change
-
Adaptation
- as soon as possible to minimize further deviation
-
Scrum Values
-
Commitment
- achieving the Scrum Team goals and to supporting each other
-
Focus
- the work of the Sprint to make the best possible progress toward these goals
-
Openness
- The Scrum Team and its stakeholders are open about the work and the challenges
-
Respect
- respect each other to be capable, independent people
-
Courage
- to do the right thing, to work on tough problems
- Trust
-
SCRUM TEAM
-
three specific accountabilities within the Scrum Team
-
Developers
-
the people that are committed to creating any aspect of a usable Increment each Sprint
- Creating a plan for the Sprint, 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
-
one Product Owner
- is accountable for maximizing the value of the product resulting from the work of the Scrum Team
-
is accountable for effective Product Backlog management
- Developing and explicitly communicating the Product Goa
- Creating and clearly communicating Product Backlog items
- Ordering Product Backlog items
- through the inspectable Increment at the Sprint Review
- Ensuring that the Product Backlog is transparent, visible and understood
- the entire organization must respect their decisions
-
one Scrum Master
- is accountable for establishing Scrum as defined in the Scrum Guide
- is accountable for the Scrum Team’s effectiveness
-
The Scrum Master serves the Scrum Team:
- Coaching the team members in self-management and cross-functionality
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done
- Causing the removal of impediments to the Scrum Team’s progress
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox
-
The Scrum Master serves the Product Owner:
- Helping find techniques for effective Product Goal definition and Product Backlog management
- Helping the Scrum Team understand the need for clear and concise Product Backlog items
- Helping establish empirical product planning for a complex environment
- Facilitating stakeholder collaboration as requested or needed
-
The Scrum Master serves the organization:
- Leading, training, and coaching the organization in its 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
-
no sub-teams or hierarchies
- focused on one objective at a time, the Product Goal
-
cross-functional
- the members have all the skills necessary to create value each Sprint
-
self-managing
- decide who does what, when, and how
-
is responsible for all product-related activities
- are structured and empowered by the organization to manage their own work
-
typically 10 or fewer people
-
too large
-
multiple cohesive Scrum Teams
- each focused on the same product
- share the same Product Goal, Product Backlog, and Product Owner
-
SCRUM EVENTS
-
The Sprint is a container for all other events
-
Events
- regularity
- minimize the need for meetings not defined in Scrum
- at the same time and place
- All the work necessary to achieve the Product Goal
-
The Sprint
-
ideas are turned into value
-
fixed length
- one month or less
- too long
- the Sprint Goal may become invalid
- risk may increase
-
During the Sprint:
- No changes are made that 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
-
to forecast progress
- burn-downs
- burn-ups
- cumulative flows
- do not replace the importance of empiricism
-
could be cancelled if the Sprint Goal becomes obsolete
- PO
-
Sprint Planning
-
initiates the Sprint
- work to be performed
- created by the collaborative work
- may also invite other people
- to discuss the most important Product Backlog items and how they map to the Product Goal
-
Topics
-
Why is this Sprint valuable?
- PO
- how the product could increase its value and utility in the current Sprint
- Team
- define a Sprint Goal
- is valuable to stakeholders
-
What can be Done this Sprint?
- PO
- Developers
- select items from the Product Backlog to include in the current Sprint
- may refine these items during this process, which increases understanding and confidence
- past performance
- upcoming capacity
- Definition of Done
- more confident in their Sprint forecasts
-
How will the chosen work get done?
- For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done
- decomposing Product Backlog items into smaller work items of one day or less
- How
- Developers!!!
-
the Sprint Backlog
- The Sprint Goal
- the Product Backlog items
- the plan for delivering them
-
is timeboxed
- a maximum of eight hours for a one-month Sprint
- shorter for shorter Sprints
-
Daily Scrum
- to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary
-
15-min
- the Developers
- if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog
-
focus and improve self-management
- WHY?
-
improve communications, identify impediments, promote quick decision-making
- eliminate the need for other meetings
- Developers often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work
-
Sprint Review
-
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
- attendees collaborate on what to do next
- The Product Backlog may also be adjusted to meet new opportunities
-
a working session
- avoid limiting it to a presentation
- The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
-
is timeboxed
- a maximum of four hours for a one-month Sprint
- shorter for shorter Sprints
-
Sprint Retrospective
- 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 Don
-
The Scrum Team discusses
- what went well during the Sprint
- what problems it encountered
- how those problems were (or were not) solved
-
The most impactful improvements are addressed as soon as possible
- may even be added to the Sprint Backlog for the next Sprint
-
is timeboxed
- a maximum of three hours for a one-month Sprint
- shorter for shorter Sprints
-
SCRUM ARTIFACTS
-
represent work or value
- maximize transparency of key information
-
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
- to reinforce empiricism
-
Product Backlog
- is an emergent, ordered list of what is needed to improve the product
-
Product Backlog refinement
-
the act of breaking down and further defining Product Backlog items into smaller more precise items
- add details
- description
- order
- size
- The Developers who will be doing the work are responsible for the sizing
- attributes
- vary with the domain of work
-
Commitment: 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 Product Goal is the long-term objective for the Scrum Team
-
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.
-
Sprint Backlog
-
is composed of
-
the Sprint Goal (why)
- is created during the Sprint Planning
- the set of Product Backlog items selected for the Sprint (what)
- actionable plan for delivering the Increment (how)
-
a plan by and for the Developers
- real-time picture of the work
-
Commitment: Sprint Goal
- the single objective for the Sprint
-
Increment
-
a concrete stepping stone toward the Product Goal
- Each Increment is additive to all prior Increment
- In order to provide value, the Increment must be usable
- The Sprint Review should never be considered a gate to releasing value.
-
Commitment: Definition of Done
- a formal description of the state of the Increment when it meets the quality measures required for the product
- The moment a Product Backlog item meets the Definition of Done, an Increment is born.
- Inspection without transparency is misleading and wasteful
-
Changes 2017-->2020
-
A little more prescriptive
- to return Scrum to the minimum sufficient framework
-
One team focused on one product
-
The goal is to eliminate the concept of a separate team
- Product Owner
- Team
- One Scrum Team focused on a common goal, with three
different areas of responsibility: Product Owner, Scrum Master and Developers
- Self-management is more important than self-organization
-
Product Goal
-
to focus Scrum Team on a broader goal
- Each Sprint should bring the product closer to the final Product Goal
- For Product Backlog there is Product Goal, For Sprint Backlog is Sprint Goal, for Increment is DOD
-
Sprint Planning. Three Questions
- WHY???
- WHAT?
- HOW?
-
General simplification of the language for a wider audience
- remaining references to IT work
-
The Scrum Guide
-
In English
- https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
-
In Russian
- https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Russian.pdf?fbclid=IwAR3ScSmMoY6je1KuQv1wi2ODsW_ytT71B59spaMN1bdIQhyyauuBqujagfY