Skip to main content Link Search Menu Expand Document (external link)
Chouffy's Notes

Scrum

Table of contents

  1. Pillars
  2. Values
  3. Context
  4. Scrum Team
    1. Product Owner
    2. Development Team
    3. Scrum Master
    4. Facilitator role
      1. Scrum Master helps Product Owner:
      2. Scrum Master helps Dev. Team
      3. Scrum Master helps organization:
  5. Events
    1. Sprint
      1. Sprint cancelling
    2. Sprint Planning
      1. What Increment can be delivered from upcoming Sprint?
      2. How will the work is done?
      3. Define Sprint Goal
    3. Daily Scrum
    4. Sprint Review
    5. Sprint Retrospective
  6. Sprint Artifacts
    1. Increment
    2. Product Backlog
    3. Sprint Backlog
    4. Definition of “Done”
  7. Other
    1. Graphics

(This is based on the 2017 edition)

Framework for developing, delivering, sustaining complex products.

  • Small team of peoples = essence of scrum
  • Founded on empiricism: knowledge comes from experience & making decisions on what is known
  • Iterative, incremental approach to optimize predictability and control risk

Must be implemented wholly.

Links:

Pillars

  • Transparency
    • Most of the process must be visible to responsible of the outcome
    • Require a common language
  • Inspection
    • Frequent inspect Scrum artifacts + Progress toward Sprint Goal = Detect variances
    • Not so frequent so it’s not counterproductive
    • Better if done by skilled inspectors
  • Adaptation
    • If deviation > acceptable = adjustment necessary ASAP

Values

  • Commitment, to do achieve goals
  • Courage, to do the right thing and solve problems
  • Focus, on their work & team goal
  • Openness, about work and challenges
  • Respect, between peoples as capable, independents peoples

The 5 above & 3 pillars build trust.

Context

  • Development is about the complex work done

Scrum Team

  • Self-organized: the team choose how best to accomplish work, rather being directed by external
  • Cross-functional: all competencies are inside

Goal - Optimize:

  • Flexibility
  • Creativity
  • Productivity

Product Owner

Responsible to manage the Product Backlog & maximize value of product and the work of the DevTeam:

  • Manage Product Backlog clearly
    • Help development team to understand items
    • Order items with desired goals & missions
    • Optimize value of the DevTeam work
    • Make Backlog visible, transparent, clear = what to do next
  • DevTeam can do above, but PO is responsible
  • PO = 1 person, can represent a committee
    • Product Marketplace Export
    • Lead facilitator of key stakeholder involvement
    • Product value maximizer
  • Organization must respect PO decision, and DevTeam work on requirement defined by it

Development Team

Deliver a potential release increment of Done at the end of the Sprint. Responsible to transform Product Backlog item into Done Increments.

  • 5~7 peoples
    • PO and Scrum Master not included unless they execute items
  • Self-organized
    • Manage their own work
    • Accountable as a whole
  • Cross-functional, can work autonomously
  • No titles
  • No sub-teams

Scrum Master

Promote & support Scrum, but not the team boss:

  • Helps to understand Scrum, inside and outside
  • Servant-leader for the Scrum
  • Help those outside the Scrum Team, protect from outside interactions

Facilitator role

Scrum Master helps Product Owner:

  • Ensure goal, scope, product domain is understood
  • Find techniques for effective Product Backlog management
    • Help Team to understand need of clear/concise Backlog items
  • Understand product planning in an empirical environment
  • Help PO for Backlog sorting
  • Facilitate Scrum events

Scrum Master helps Dev. Team

  • Coach the DevTeam to be self-organized and cross-functional; or help implementing
  • Help DevTeam to create high-values products and remove roadblocks
  • Facilitate Scrum events

Scrum Master helps organization:

  • Leading, coach, plan Scrum adoption/implementations
  • Help understanding Scrum
  • Cause change to improve productivity
  • Work with Scrum Masters to increase Scrum application effectiveness

Events

  • Goal: minimize needs for other meetings
  • All events are time-boxed (max duration)
  • Sprint is a container for all other events
    • Sprint size is fixed
    • Each events helps to Inspect & Adapt

Sprint

Time box to create a useable, releasable “Done” of a Product Increment

  • Restart immediately each <= 1 month, usually 2 weeks
  • Has a goal of what is going to be built, the work to do and the resultant
  • Contain the all Events below
  • No changes can be made that could endanger the Sprint Goal
  • Scope can be clarified & re-negociated with PO <> DevTeam

Sprint cancelling

  • Sprint can be cancelled by PO if the Sprint Goal is obsolete
    • Due to company direction or market
  • All “Done” items are reviewed
    • Complete items can be accepted by PO
    • Uncompleted are re-estimated and put on Backlog

Sprint Planning

Planning of the work to be done during Sprint

  • Maximum 8h for 1 month Sprint, with entire Scrum team
  • Input:
    • Product Backlog
    • Projected capacity
    • Product Increment
    • Past Performance of the Dev Team

Following questions are answered:

What Increment can be delivered from upcoming Sprint?

  • DevTeam forecast all work to develop functionality
  • PO discuss Sprint objective and Backlog items that would achieve Sprint Goal
  • /# items depends on the DevTeam
  • Only the DevTeam can assess what it can do in a Sprint

How will the work is done?

  • Discussion by DevTeam how a Backlog item will be Done
    1. Design the system
    2. Forecast work to convert Product Backlog into working Increment
    3. Decompose work in units <= 1 day
      • Only for the first days of the Sprint
    4. DevTeam can explain to PO and Scrum Master how it intends to work as a team to accomplish Sprint Goal and create Increment
  • Enough work is planned to make the Sprint Goal possible
  • DevTeam self-organize works in the Sprint Backlog, both in Planning and during Sprint

Define Sprint Goal

  • Objective that will be met during Sprint through Backlog implementation
    • Set of coherent Backlog items
    • But can be other coherent to help DevTeam to work together
  • Provide guidance to DevTeam on why
  • Sprint Goal is satisfied by implementing functionality & technology
  • If works is different than DevTeam expect, they collaborate with PO to negotiate scope
  • Defined by the Scrum Team after the Dev Team forecast the product Backlog that will be delivered in the Sprint

Daily Scrum

Plan the work for the next 24h

  • =15 min with DevTeam only, same time & place to reduce complexity
    • Scrum Master ensure the meeting is done, and start it
    • DevTeam directs it and only they participate
  • Helps team collaboration & performance
    • Inspect
      • Work since last Daily Scrum
      • Progress toward Sprint Goal
      • Progress to complete Sprint Backlog
    • Forecast Sprint work
  • Format
    • Up to the team: question, discussion, …
      • What did I do yesterday to help DevTeam meet Sprint Goal?
      • What will I do today to do the same?
      • Do I see issues preventing me/DevTeam to reach goal?
  • DevTeam can convene just after for detailed discussion

Sprint Review

Inspect the increment, adapt Product Backlog

  • Max 4h
    • Team and key stakeholder
  • What has been done
    • But it’s not an approval of what has been done
    • Stakeholder can give feedback
  • What are the faced problem
  • Demo of the work
  • Discussion, adaptation of the product backlog
  • Planning of what’s next = a revised Product Backlog
  • Review of timeline

Sprint Retrospective

Create a plan for improvement during next sprint

  • Max 3h
  • Dimension of inspection
    • People
    • Relationship
    • Process & Tools
  • Improvement initiatives can be added to next sprint or implemented anytime

Sprint Artifacts

Increment

Sum of all Product Backlog completed during Sprint + Value of increments of all previous Sprint

Product Backlog

Single source of requirements, even if multiple teams

  • Ordered list of need that needs to be done, defined by Product Owner
  • PO is responsible for the Backlog, but DevTeam can also change it
  • Backlog refinement
    • Details can be added
    • Complexity of the task is assessed
    • Max 10% of the capacity of the DevTeam
  • Dev. team is responsible for all estimates
  • PO tracks total work remaining

Sprint Backlog

Set of product backlog items selected for the Sprint = selected Product Backlog items + plan for deliver them

  • Belongs solely / Owned by DevTeam
  • Include at least one item from last Retrospective
  • Fixed during Sprint Planning. Only Dev. Team can change during Sprint and ASAP if necessary
  • Visible picture to see what needs to be accomplish

Definition of “Done”

Shared definition

  • Increase transparency, defined by the development organization (or the Dev Team)
  • Defined by the Development Team, for the Development Team
    • The minimum can also be defined by the organization
    • If multiple teams, all team must agree on the same definition of Done
    • As the team maturity increase, so the definition of Done criteria
    • Guide also the # of Product Backlog item the team can take during a Sprint
  • Used to assess when work is complete on the increment
    • This increment is useable, so PO can immediately release it
    • Each increment is additive to all Increments and are tested

Other

Graphics

  • Cone of Uncertainty: How much is known about the Product over time
  • Burn-down chart: How much work remains till the end of the Sprint
  • Release burn-down: A measure of remaining Product Backlog across the time of a release plan