All about the scrum

Definition of Ready Scrum Guide

/0 Comments/in /by
  1. Business value is clearly articulated.
  2. Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the PBI. 
  3. Dependencies are identified and no external dependencies would block the PBI from being completed. 
  1. The team is staffed appropriately to complete the PBI. 
  2. The PBI is estimated and small enough to comfortably be completed in one sprint. 
  3. Acceptance criteria are clear and testable.
  4. Performance criteria, if any, are defined and testable. 
  5. The Scrum team understands how to demonstrate the PBI at the sprint review. 

The Sprint Retrospective

/0 Comments/in /by
  1. The main purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
  2. The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools, and their Definition of Done.
  1. It is a 3-hour event for a 1-month Sprint. For shorter Sprints, it’s usually shorter.
  2. It is an opportunity to inspect and adapt the process the Scrum Team has been using to build the increments.
  3. The whole Scrum Team attends the event.
  4. . During the Sprint Retrospective, we examine how we build the product, not the product itself.

The Sprint Review

/0 Comments/in /by
  1. The purpose of the Sprint Review event is to 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.
  2. Attendees of the Sprint Review event are the Scrum Team and key stakeholders.
  3. Sprint Review is not just a demo or a presentation of the increment.
  1. The Scrum Team only presents items that are 100% done according to the DoD.
  2. If a customer routinely skips this event, the expectations of the Scrum Team and the customer would become misaligned and both parties would not be happy.
  3. The Product Backlog may also be adjusted to meet new opportunities.
  4. The Sprint Review is a 4-hour event for a 1-month Sprint. For shorter Sprints, it’s usually shorter.

The Sprint

/0 Comments/in /by
  1. “Sprints are the heartbeat of Scrum, where ideas are turned into value.” – Scrum Guide
  2. The purpose of Sprint is to create usable increments. A Sprint is like a small project.
  3. A new Sprint begins immediately after the previous one ends.
  4. A Sprint is one month or shorter in length.
  1. The Sprint is a container for all the other Events. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happens within Sprints.
  2. When the risk is higher, shorter Sprints are preferred, to generate more learning cycles.
  3. A Sprint can be canceled when the Sprint Goal becomes obsolete by the Product Owner.
  4. Sprint cancellation is bad for the team, and it requires regrouping of the team, and a new Sprint Planning event, as a result, resources are lost.
  5. During the Sprint quality goals do not decrease, but scope might be re-negotiated.

Daily Scrum

/0 Comments/in /by
  1. The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and adapt the Sprint Backlog if needed.
  2. Daily Scrum is for Developers. It is mandatory for all Developers of the Scrum Team.
  3. The SM ensures that Daily Scrum takes place, and is kept to 15 minutes, but the Developers are responsible for conducting the event.
  1. During Daily Scrum, the Developers plan the work for the next day.
  2. The SM and PO are allowed to attend but not participate in Daily Scrum.
  3. The SM and PO can participate in Daily Scrum as “Developers” if they are actively
  4. working on Sprint Backlog Items.
  5. Daily Scrum is always 15 minutes regardless of Sprint length and number of Developers.

The Sprint Backlog

/0 Comments/in /by
  1. The Sprint Backlog (SB) consists of 3 things:
    • The Sprint Goal (which is the why)
    • The selected PBIs (which is the what)
    • The Plan for delivering the Increment (which is the how).
  1. The SB is a plan by and for the Developers.
  2. . The SB should be highly-visible i.e. transparent
  3. The SB changes during the Sprint (BUT the Sprint Goal does not)
  4. The PO and the Developers may change/negotiate the scope of the Sprint but this should not affect the Sprint Goal in any way.
  5. We move the incomplete items back to the Product Backlog for future consideration.

Sprint Planning

/0 Comments/in /by
  1. During Sprint Planning, the PO ensures that attendees are prepared to discuss the most important PBIs and how they map to the Product Goal.
  2. During Sprint Planning we answer three important questions: a) Why is this Sprint Valuable? b) What can be done this Sprint? c) How will the chosen work get done?
  3. The entire Scrum Team attends and collaborates on creating the Sprint Goal.
  4. The Developers decide how many PBIs to select for the Sprint Backlog.
  1. The developers decide on the practices to use to turn PBIs into a usable increment.
  2. The more the Developers know about their past performance, upcoming capacity, and the DoD, the more accurate forecasts they will be able to do.
  3. The Sprint Backlog is created during Sprint Planning and it is a combination of 3 things. i) The Sprint Goal ii) the selected PBIs, and iii) a Plan to deliver them.
  4. The Scrum Team may invite other people to attend Sprint Planning to provide advice.
  5. Sprint Planning is 8 hours for a 1-month Sprint and is usually shorter for shorter Sprints.

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.