Skip to content

SCRUM

About Scrum

  • Definition:
    • =**A framework **
      • address complex adaptive problems
      • productively and creatively delivering products of the highest possible value
        • developing, delivering, and sustaining complex products
      • consists of Scrum’s roles, events, artifacts, and the rules that bind them together
      • within SCRUM you can employ various processes and techniques (ex: Suite de Fibonacci, MoSCoW…)
    • Iterative and provide incremental knowledge transfer
    • The essence of Scrum is a small team of people
    • The individual team is highly flexible and adaptive
      • Agility
      • Flexibility
      • Productivity
    • Scrum’s roles, events, artifacts, and rules are immutable
      • Implementing only parts of Scrum is possible however the result is not Scrum
      • Scrum exists only in its entirety
    • Is empirical
  • Scrum Theory:
    • Employs an iterative, incremental approach to optimize predictability and control risk
      • Maximize opportunities for feedback
    • Three pillars uphold every implementation of empirical process control:
      • Transparency:
        • Significant aspects of the process must be visible to those responsible for the outcome.
        • Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen
      • Inspection:
        • Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
        • Frequently but shouldn't get in the way of the work
      • Adaptation:
        • When one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted
        • 4 formal events for inspection and adaptation:
          • Sprint Planning
          • Daily Scurm
          • Sprint Review
          • Sprint Retrospective
  • Scrum Values:
    • Commitment
    • Courage
    • Focus
    • Openness
    • Respect
    • Successful use of Scrum depends on people becoming more proficient in living these five values

The Scrum Team

  • Scrum Teams are:
    • Self-organizing and cross-functional
    • Choose how best to accomplish their work, rather than being directed by others outside the team
    • Have all competencies needed to accomplish the work without depending on others not part of the team
  • The Product Owner:
    • Is one person
    • The sole person responsible for managing the Product Backlog
      • Clearly expressing Product Backlog items;
      • Ordering the items in the Product Backlog to best achieve goals and missions;
      • Optimizing the value of the work the Development Team performs;
      • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
      • Ensuring the Development Team understands items in the Product Backlog to the level needed.
    • Is accountable for the Product Backlog but may not do the work by himself
    • The entire organization must respect his or her decisions
  • The Development Team:
    • Do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint
    • Is responsible for managing the progress of work during a Sprint
    • Is self-organizing.
      • No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
    • Is cross-functional, with all the skills as a team necessary to create a product Increment:
      • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
      • No titles for Development Team members, regardless of the work being performed by the person;
      • No sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;
    • Size:
      • Small enough to remain nimble and large enough to complete significant work within a Sprint.
      • < 3 Development Team members decrease interaction and results in smaller productivity gains

      • 9 members requires too much coordination

      • PO & SM not included in the count unless they're also executing the work of a Sprint Backlog
  • The Scrum Master:
    • Responsible for promoting and supporting Scrum as defined in the Scrum Guide.
    • Help everyone understand Scrum theory, practices, rules, and values.
    • Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t
    • Serves the PO:
      • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
      • Finding techniques for effective Product Backlog management;
      • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
      • Understanding product planning in an empirical environment;
      • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
      • Understanding and practicing agility; and,
      • Facilitating Scrum events as requested or needed.
    • Serves the DevTeam:
      • Coaching the Development Team in self-organization and cross-functionality;
      • Helping the Development Team to create high-value products;
      • Removing impediments to the Development Team’s progress;
      • Facilitating Development Team decisions
      • Facilitating Scrum events as requested or needed; and,
      • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
    • Serves the Organization:
      • Leading and coaching the organization in its Scrum adoption;
      • Planning Scrum implementations within the organization;
      • Helping employees and stakeholders understand and enact Scrum and empirical product development;
      • Causing change that increases the productivity of the Scrum Team; and,
      • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The Scrum Events

  • Events are used to:
    • create regularity
    • minimize the need for meetings not defined in Scrum
  • All events are time-boxed (max duration)
  • Other than the Sprint event, each event in Scrum is a formal opportunity to inspect and adapt something
  • The Sprint:
    • Rules:
      • A time-box of one month or less
        • No more than one month horizon
      • Have a consistent duration
      • A new one starts immediatly after the conclusion of the previous
      • During the Sprint:
        • No changes are made that would endanger the Sprint Goal;
        • Quality goals do not decrease; and,
        • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
      • Cancelling a Sprint:
        • Only by the PO
        • Before the Sprint time-box is over
        • if the Sprint Goal becomes obsolete
        • Any completed and "Done" Product Backlog items are reviewed
        • All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
        • If part of the work is potentially releasable, the Product Owner typically accepts it
    • Goal:
      • A "Done", useable, and potentially releasable product Increment is created
    • Activities:
      • Sprint Planning
      • Daily Scrums
      • Development work
      • Sprint Review
      • Sprint Retrospective
  • The Sprint Planning:
    • Rules:
      • Attendees:
        • The Scrum Team:
          • PO
          • Scrum Master
          • DevTeam
      • Time-boxed to a maximum of eight hours for a one-month Sprint
    • Goals:
      • Define the work to be performed in the Sprint
      • What can be delivered in the Increment resulting from the upcoming Sprint?
        • The Development Team works to forecast the functionality that will be developed during the Sprint.
        • Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items
        • Input to this meeting is:
          • Product Backlog
          • The latest product Increment
          • Projected Capacity of the Development Team during the Sprint
          • Past performance of the Development Team
        • Scrum Team also crafts a Sprint Goal
      • How will the work needed to deliver the Increment be achieved?
        • Product Backlog items selected for this Sprint + the plan for delivering them is called the Sprint Backlog
        • Work may be of varying size, or estimated effort
        • Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less
        • If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner
    • By the end of the Sprint Planning The Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
    • Sprint Goal:
      • Objective set for the Sprint that can be met through the implementation of Product Backlog
      • Defined by the Scrum Team
      • Created during the Sprint Planning
      • Can be any coherence that causes the DevTeam to work (ex: common goals of the Pbi)
      • Provide guidance to the DevTeam on why it is building the increment
  • The Daily Scrum:
    • Rules:
      • Attendees:
        • DevTeam: Required to attend
        • Scrum Master:
          • Not allowed to attend, if so this is only because others are present and he ensures that they don't disrupt the meeting
          • Not required to attend
          • Teach the Development Team to keep the Daily Scrum within the 15 minute time-box.
          • Enforces the rule that only Development Team members participate in the Daily Scrum
      • 15-minute time-boxed event for the Development Team
      • Held every day at the same time and place to avoid complexity
      • Structure of the meeting is set by the DevTeam
    • Goals:
      • Inspecting the work since the last daily scrum
      • Planning the work for the next 24h
      • = is a key inspect & adapt meeting
  • The Sprint Review:
    • Rules:
      • Attendees:
        • The Scrum Team: PO, Scrum Master, DevTeam
        • Key stakeholders invited by the PO
      • Held at the end of the Sprint
      • At most a four-hour meeting for one-month Sprints
    • Goals:
      • = reflexion sur le fond
      • Inspect the Increment and adapt the Product Backlog if needed
      • Highlight of what was done in the sprint
      • Collaborate on the next things that could be done to optimize value
      • It is when the Scrum Team and stakeholders inspect the outcome of a Sprint and figure out what to do next.
    • Activities:
      • The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
      • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
      • The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
      • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
      • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
      • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
      • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
  • The Sprint Retrospective:
    • Rules:
      • Occurs after the Sprint Review and prior to the next Sprint Planning
      • At most a three-hour meeting for one-month Sprints
    • Goals:
      • = reflexion sur la forme
      • Opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
      • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
      • Identify and order the major items that went well and potential improvements; and,
      • Create a plan for implementing improvements to the way the Scrum Team does its work
        • = New item within the Sprint Backlog
        • This is not mandatory
        • Is a way to update the Definition of Done

The Scrum Artifacts

  • Product Backlog:
    • Ordered list of everything that is known to be needed in the product
    • Evolves as the product and the environment in which it will be used evolves
    • Items have the attributes of a description, order, estimate, and value
    • Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog
      • Usually consumes no more than 10% of the capacity of the Development Team
    • The Development Team is responsible for all estimates
    • The Product Owner is the sole person responsible for managing the Product Backlog
    • When multiple teams work together on the same product, they should have all the same product backlog
    • At any point in time, the total work remaining to reach a goal can be summed
  • Sprint Backlog:
    • Set of Pbi selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal
    • Belongs solely to the DevTeam:
      • Forecasted by the DevTeam
      • Only the Development Team can change its Sprint Backlog during a Sprint
    • At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed
      • By the DevTeam
  • Increment:
    • = sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints
    • Created by the DevTeam
    • At the end of a Sprint the new Increment must be "Done"
    • An increment is a body of inspectable done work
    • The Increment is useable so could be released at any point in time
  • Artifact Transparency:
    • Decisions to optimize value and control risk are made based on the perceived state of the artifacts
  • Definition of "Done":
    • Defined by the dev org / dev team:
      • The development organization (or Development Team if none is available from the development organization)
    • Everyone must understand what "Done" means
      • Must have a shared understanding of what it means
    • Used to assess when work is complete on the product Increment.
    • The definition must be appropriate to the product
    • Any one product or system should have a definition of "Done" that is a standard for any work done on it.
    • When multiple dev team:
      • All Development Teams must have a definition of "Done" that makes their combined work potentially releasable
    • Can be reviewed and adapted during each sprint retrospective

Certification PSM 1