The Time-Box

/0 Comments/in /by
  1. Scrum Events are Timeboxed i.e. they have a maximum duration not to be exceeded.
  2. A Sprint can be a maximum of 1 month and a minimum of 1 week.
  3. Scrum Teams choose the length of the Sprint.
  4. For a 1 month Sprint
    • Sprint Planning = 8 hours
    • Sprint Review = 4 hours
    • Sprint Retrospective = 3 hour
    • Daily Scrum is always 15 minutes
  1. When a Sprint is less than 1 month, the other events are usually proportionately shorter, but this is not a requirement.
  2. All Events can vary in length based on the length of the Sprint, except the Daily Scrum.
  3. All Scrum Events, besides the Sprint, can end early when the purpose of the event is achieved.

The Developers

/0 Comments/in /by
  1. The Developers are the people in the Scrum Team who create any aspect of a usable increment during the Sprint.
  2. The specific skills of the Developers will vary a lot depending on the work domain, i.e. they do not have to be software developers. Still, they could be scientists, researchers, manufacturers, etc.
  1. The Developers create the plan for Sprint, this is the Sprint Backlog.
  2. The Developers choose how many PBIs need to be included in a Sprint.
  3. They are responsible for sizing (estimating) the PBIs and the techniques they would use to turn PBIs into usable increment
  4. Developers participate in Daily Scrum and come up with an actionable plan for the day.
  5. Developers are required to conform to the DoD (Definition of Done)
  6. The Developers hold each other accountable as professionals.

The Definition of Done

/0 Comments/in /by
  1. “The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the Product”. – The Scrum Guide 2020
  2. The moment a PBI meets the DoD, an Increment is born.
  3. The DoD is mandatory and it increases transparency.
  1. If DoD is part of organizational standards, the Scrum Team must follow it as a minimum.
  2. If DoD is not part of organizational standards, the Scrum Team must create one that is appropriate for the Product.
  3. PBI’s that do not meet the DoD cannot be released or presented at the Sprint Review.
  4. If multiple Scrum Teams are working on the same Product, they must mutually define and comply with the same DoD for the integrated increment.
  5. The DoD is not the same as Acceptance Criteria. DoD applies to all PBIs whereas Acceptance Criteria are written for each PBI.

The Increment

/0 Comments/in /by
  1. An Increment is a stepping stone toward the Product Goal.
  2. Each Increment is additive to all prior increments.
  3. The sum of all Increments is presented to Stakeholders at the Sprint Review. However, Increments can be released to Stakeholders at any time.
  1. The Scrum Team has to create one or more useful Increments each Sprint.
  2. All Increments must be verified and usable.
  3. The whole Scrum Team decides when to release an Increment.
  4. Multiple increments can be released to stakeholders during a Sprint.
  5. Work cannot be considered part of an Increment unless it meets the Definition of Done (DoD).
  6. The commitment for the Increment is the DoD.

The Sprint Goal

/0 Comments/in /by
  1. The Sprint Goal is a Single Objective for the Sprint.
  2. The Developers make a commitment to delivering the Sprint Goal.
  3. While the Sprint Goal is a commitment by the Developers, it provides flexibility on the exact work needed to achieve the goal.
  1. The Sprint Goal is set by the Scrum Team during Sprint Planning and then added to the Sprint Backlog.
  2. The PO and the Developers may negotiate the scope of the Sprint without affecting the Sprint Goal
  3. The PO can cancel a Sprint if he/she decides the Sprint Goal is no longer valid. Only the PO is allowed to cancel the Sprint

The Scrum Master

/0 Comments/in /by
  1. The Scrum Master (SM) is accountable for:
    • Establishing Scrum (as per the Scrum Guide) in the Scrum team and the Organization
    • The Scrum Teams effectiveness
  2. The SM is a true leader who serves:
    • The Scrum Team by:
      • Causing the removal of impediments to the Scrum Team’s progress
      • Ensuring that all Scrum events that take place and are positive, productive, and kept within the timebox
    • The Product Owner by:
      • Helping find techniques for effective Product Goal Definition & Product Backlog Management
      • Facilitating stakeholder collaboration as needed.
    • The Organization by:
      • Leading, coaching & training them on Scrum adoption.
  1. If the SM (or PO) is actively working on PBIs in a Sprint, they do so as “developers”.
  2. The SM acts as a team coach and teacher. They manage not the people but the process.
    • They possess what’s called “Process Authority” and make sure everyone understand and embraces the Scrum theory, values, rules, and practices.
  3. The Scrum Master is NOT a Project Manager
    • A Project Manager role does not exist in Scrum
  4. The SM can work part-time as well as full-time.
  5. Scrum doesn’t prohibit one person to act as a SM and a PO but it doesn’t recommend it either.
  6. The SM can work on multiple Products & Product Teams.

The Product Goal

/0 Comments/in /by
  1. The Product Goal describes a future state of the Product. It is the long term objective for the Scrum Team.
  2. The Scrum Team must fulfill or abandon one Product Goal before taking on another.
  3. Therefore a Scrum Team can only have 1 Product Goal at a time.
  4. The PO is responsible for creating and communicating the Product Goal.
  5. The Scrum Master helps the PO find techniques for effective Product Goal definition.
  1. The increment is a stepping stone toward the Product Goal.
  2. The Product goal is a stepping stone toward the broader Product Vision.
  3. The Product Goal should be measurable. The team should know when it’s achieved.
  4. The Product Goal can be changed, but it is unlikely to happen during a Sprint.
  5. Progress toward the Product Goal is discussed with stakeholders during Sprint Review.

The Product Backlog

/0 Comments/in /by
  1. The Product Backlog (PB) is an ordered list of what is needed to improve the product.
  2. The PB is the single source of work undertaken by the Scrum Team.
  3. Product Backlog Items (PBIs) that can be completed in 1 Sprint are considered “ready” for selection for a Sprint during Sprint Planning.
  4. The Product Owner orders the PB in a way to maximize product value.
  5. The Product Backlog will exist as long as the Product exists. It is ever-changing and dynamic.
  1. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This includes adding detail such as:
    • Description
    • Order
    • Size
    • Etc
  2. PBI attributes (e.g. description, order) often vary depending on the domain of work.
  3. PBI’s on the top of the PB are more refined and hence smaller than PBI’s at the bottom.
  4. The Product Backlog can be refined at any time as needed.
  5. Multiple Scrum teams can share the same Product (and they would then have the same
  6. Product Backlog, Product Owner & Product Goal).
  7. Only the Developers can determine the size (estimate effort involved) for Product Backlog Items.
  8. Product Backlog Refinement is an ongoing activity done by the PO and the Developers.
  9. “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.” – Scrum Guide 2020.

Scrum Artifacts

/0 Comments/in /by
  1. There are 3 Scrum Artifacts:
    • The Product Backlog
    • The Sprint Backlog
    • The Increment
  2. Each Scrum Artifact contains a commitment to ensure it provides information that enhances transparency and focus.
    • 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.
  3. The three commitments are mandatory.
  4. The PO works with the Scrum Team and creates the Product Goal.
    • The PO is accountable for the Product Goal.
  5. The entire Scrum Team creates and is accountable for the Sprint Goal.
  6. The entire Scrum Team creates and is accountable for the Definition of Done.

The Product Owner

/0 Comments/in /by
  1. Only the PO can cancel the Sprint.
  2. The PO is the expert on the marketplace for the Product.
  3. During Sprint Planning, the PO brings a business objective, based on which the Scrum Team crafts a Sprint Goal.
  4. There can only be one PO for a product. But a PO can work on multiple products.
  5. During Sprint Review, the PO seeks feedback from key stakeholders.
  6. A PO can also work as a developer on the team.
  7. The PO can attend, but cannot “participate” in Daily Scrum meetings, except in the capacity of a developer.
  8. The PO can attend but cannot participate in any PBI sizing (estimation) activities e.g. during Sprint Planning