Scrum - Rituals

  • Iterative Time-Boxes

    • Iteration 1 -> increment (product)

      • Analyze

      • Design

      • Construct

      • Integrate

      • Test

    • Iteration 2 -> increment (product)

      • Analyze

      • Design

      • Construct

      • Integrate

      • Test

    • Iteration 3 -> increment (product)

      • Analyze

      • Design

      • Construct

      • Integrate

      • Test

  • Sprint

    • The heart of Scrum.

    • One month or less.

    • Time box for creating an Increment.

    • Team determines length based upon their belief of what would work best to enhance team productivity.

    • Note that

      • Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

      • Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

      • Potentially shippable piece of product at each end of Sprint/Increment.

      • Can never be lengthened when work is not done!

      • The three pillars of Scrum are Transparency, Inspection, and Adaptation.

  • Sprint Duration

    • Time-boxed.

      • 2 - 4 weeks.

    • Short and consistent duration.

    • Goal should not be altered after sprint begins.

    • Attempts to reach the end state specified by the Definition of Done.

    • Recurring timeframe could be changed only for a very good reason.

  • Rituals During the Sprint

    • Sprint Planning -> Beginning of every sprint

    • Daily Stand-ups -> Designated time every day

    • Development work -> Team members perform work every day to move sprint forward towards achieving the sprint goal

    • Sprint Review -> A scheduled meeting where the completed increment is demonstrated to stakeholders and feedback about increment viability is received by the team

    • Sprint Retrospective -> The final meeting of a sprint where team members evaluate how well they performed as a team in this sprint. The goal of this meeting is to look for ways that the team can improve their productivity and increase their velocity

  • Sprint Planning Session

    • Sprint Planning Meeting

      • The Sprint Planning Meeting is a Scrum event that occurs at the beginning of each Sprint. During this meeting, the Scrum Team, including the Product Owner, Scrum Master, and the Development Team, collaborate to define the Sprint Goal and determine the work that will be done during the upcoming Sprint.

    • Inputs to Sprint Planning

      • Definition of Done

      • Product Backlog

      • Retrospective

      • Commitments

      • Development Team (velocity + capacity)

    • Questions to be answered by Sprint Planning

      • What

        • Sprint goal gives direction to team. Analysis, evaluation, and selection from Product Backlog defines Sprint Backlog

      • How

        • Create an actionable plan for delivery. Ensure the right amount of work is tackled.

      • Outputs of Sprint Planning

        • Sprint Goal

        • Sprint Forecast

        • Sprint Backlog

      • Estimation

        • The act of determining (guessing) the expected size of something.

        • In Scrum, estimating helps to set expectations as to the amount of work that can be performed or the length of time until something is finished.

    • Scrum Roles Involved in Estimation

      • Product Owner -> Describes and Clarifies, clarify the requirements of the Product Backlog item

      • Scrum Master -> Coaches and Facilitates

      • Scrum Team -> Estimates Collaboratively

    • Triangulation - Planning Poker

      • Remember Planning Poker?

        • Relate estimates.

        • Consensus.

        • Precision.

      • Note that

        • One of the most popular ways of estimating user stories is by playing estimation poker, sometimes called Planning Poker. This is a game to determine user story size and to build consensus with the development team members.

        • To play it, you need a deck of cards with numbers of the Fibonacci sequence on the cards.

        • Some rules to follow:

          • Product Owner reads out high-priority user story.

          • Each player selects a card representing estimate of effort involved.

          • All players return their cards simultaneously.

          • Discuss outcomes and translate size to time needed to get it ‘done.’

        • Story Points provide information on the Velocity of a team

        • Estimating is always an approximation

        • Periodically re-estimate Story Points

        • Triangulation – Planning Poker

          • Relate estimates: 2 pt story should be half of 4 pt etc.

          • Do we still agree on meaning of a story point

          • Precision decreases with size of story

    • Planning Poker

      • Determining the amount of work each PBI entails.

      • Based on the Fibonacci Sequence.

      • Each development team member is issued one set of cards.

      • If when hands are shown, there is not a clear agreement on the amount of work involved, then high and low bidders will explain why they chose that bid.

      • The team will re-vote until they come to a consensus.

    • Triangulation Board: Another way of sizing user stories

      • Each user story is placed into a bucket with like-sized user stories to help with estimation.

      • Blind Estimation requires quite some background work

      • Affinity Estimation can be done in relative short time

        • Write your user stories on post-its

        • Take one min to agree on category: XS/S/M/XL/too large

        • Take 30 seconds per user story to categorize

        • Product Owner reviews

      • Blind Estimation

        • Estimate product backlog

        • Decompose reference story

        • Identify team capacity

        • Estimate team velocity

      • Affinity Estimating

        • Quickly categorize user stories

        • Apply estimates to categories

        • Fast and Furious...

    • Types of Estimation

      • Portfolio Backlog

      • Product Backlog

      • Sprint Backlog Tasks

    • When Estimation Occurs

      • When estimation

        is performed

        Portfolio Planning

        Product

        Backlog Grooming

        Sprint Planning

        Unit of measure

        T-shirt sizes

        Story points / ideal days

        Ideal hours / effort-hours

      • The 3 types of estimation in Scrum are:

        • Story Point Estimation

        • Ideal Time Estimation

        • T-Shirt Size Estimation

      • When this occurs

        • Estimation typically occurs during the Sprint Planning Meeting

      • Unit of measure

        • Story Point Estimation: A relative measure of the effort required to complete a user story or product backlog item, without assigning a specific time duration or effort value.

        • Ideal Time Estimation: A measure of the amount of time it would take for a team member to complete a task or user story, assuming no interruptions or distractions.

        • T-Shirt Size Estimation: A measure of the relative size or complexity of a user story or product backlog item, represented by t-shirt sizes (XS, S, M, L, XL).

      • Estimation
        When this occurs
        Unit of measure

        Story Point Estimation

        This type of estimation occurs during the Sprint Planning Meeting when the team estimates the effort required to complete each user story in the Product Backlog

        The unit of measure is abstract points that represent the effort required, rather than actual hours

        Ideal Time Estimation

        This type of estimation occurs during the Sprint Planning Meeting when the team estimates the amount of time required to complete each user story in the Product Backlog

        The unit of measure is hours or days

        T-Shirt Size Estimation

        This type of estimation occurs during the Product Backlog Refinement meeting when the team assigns T-Shirt sizes (XS, S, M, L, XL, XXL) to user stories based on their relative complexity. The unit of measure is

        The unit of measure is a relative size, rather than actual hours or points

    • Problems with Estimating in Ideal Days/Hours

      • Ideal day/ideal hour is a unit of measurement used in Scrum to estimate the effort required to complete a task or user story.

      • An ideal day is the amount of effort that an average team member can complete in a day, assuming there are no interruptions or distractions.

      • An ideal hour is the amount of effort that can be completed in an hour, again assuming no interruptions or distractions.

      • The purpose of using ideal day/ideal hour is to provide a consistent and realistic way to estimate the time required to complete a task, without taking into account factors such as team member availability, meetings, or other distractions.

      • Ideal hour:

        • Focus on the task; No interruptions.

      • Ideal day:

        • Constantly able to focus; No interruptions.

  • Daily Stand-Up

    • The Daily Stand-up, also known as Daily Scrum, is a time-boxed event in Scrum where the Development Team meets for 15 minutes every day to synchronize activities and create a plan for the next 24 hours.

    • The purpose of the Daily Stand-up is to:

      1. Inspect progress toward the Sprint Goal and make adaptations to the Sprint Backlog or the Sprint Goal, if needed.

      2. Identify any impediments or roadblocks that are preventing the team from meeting their commitments or achieving the Sprint Goal.

      3. Provide an opportunity for team members to share updates on their work and discuss any dependencies or overlaps with other team members.

      4. Foster team collaboration, transparency, and communication.

    • Accountability and Support Questions

      • What did you do since the last meeting?

      • What are you planning to do before the next meeting?

      • Do you experience any obstacles?

    • Adapt the plan for the next 24 hours to ensure that we move

      forward toward a successful increment.

    • The rules for the Daily Standup (also known as Daily Scrum) in Scrum include:

      1. The meeting should be held at the same time and place every day.

      2. The meeting should be timeboxed to 15 minutes or less.

      3. The Development Team should attend and participate.

      4. The Scrum Master should facilitate the meeting.

      5. The Product Owner and stakeholders can attend but should only listen and not interrupt.

      6. Each team member should answer three questions:

        1. What did you do yesterday?

        2. What will you do today?

        3. Are there any obstacles or impediments in your way?

      7. The meeting is not a status update or problem-solving session, but a coordination and planning session for the Development Team.

      8. If any issues or concerns are raised, the Development Team should follow up after the meeting to address them.

    • The Development Team uses the Daily Stand-up to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

    • The Scrum Master asks the questions. Same place and time every day. For synchronization, not problem-solving. A short meeting may be held after the Scrum meeting to resolve issues (only attended by relevant team members). Time box: 15 minutes daily. It works best if you do it in the early hours of a day. With distributed team: find core hours (see module 5).

  • Pair Programming

    • Collective code ownership!

      • All team members understand the code.

    • Two team members; one task.

      • Driver and navigator.

    • Constant reflection (real-time reviewing).

    • Reduction of noise.

    • In Pair programming, two developers work together on the code. Both sit at the same computer and create one requirement. They pass the keyboard and mouse back and forth to collaborate. This way they catch errors easily.

    • Ensure that everyone knows what the code does.

      • Collective code ownership!

        • Two team members work together in single task.

      • Driver and navigator

      • Constant reflection (real time reviewing).

      • Reduction of noise.

  • Sprint Review Meeting

    • Informal; No PowerPoints!

    • Demo meeting.

    • 4 hours max.

    • Elicit feedback.

    • Foster collaboration.

    • Story of the journey.

    • Aspect
      Description

      Purpose

      To review the progress of the current sprint and gather feedback from stakeholders. Foster collaboration.

      Participants

      Scrum team, Product Owner, Stakeholders, Management.

      Timing

      Typically held on the last day of the sprint. 4 hours max.

      Location

      Ideally in a space where stakeholders and team members can come together and have a discussion, whether that be in person or virtually.

      Expected Outcomes

      - Review of the work completed during the sprint. - Discussion of any challenges or obstacles that were encountered. - Feedback from stakeholders on the completed work. - Identification of any changes or adjustments that need to be made for the next sprint. - Potential adjustments to the product backlog.

    • External stakeholders, such as technical architects, may be invited to the Sprint Review Meeting to voice their opinion.

      A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

    • The Scrum Master is responsible for coordinating and conducting this meeting. It should take no more than 4 hours (time box)

    • During this meeting

      • ✓The team tells the story of its journey during the Sprint

      • ✓The team delivers the product Increment built during the Sprint to management, customers, users and the Product Owner

      • ✓The team follows the demo meeting with a Sprint Retrospective to learn from their experiences this Sprint

      • ✓PowerPoint presentations are forbidden!

  • Sprint Retrospective Meeting

    • Last activity in a sprint.

    • 3 hours max.

    • Reflect on sprint.

    • Improvements of process for future.

    • Review ‘Definition of Done.’

    • What worked well? -> What could be improved? -> What will the team commit to doing in the next sprint? -> Scrum Team members make individual actionable commitments.

    • The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.

    • The Scrum Master is responsible for coordinating and conducting this meeting. It should take no more than 3 hours (time box)

    • The team follows the demo meeting with a Sprint Retrospective

    • Purpose:

      • 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

      • Create a plan for implementing improvements to the way the Scrum Team does its work

  • Ritual Timing

    • Maximum duration:

      • Sprint: 1 month.

      • Daily Stand-up: 15 minutes.

      • Sprint Planning: 8 hours.

      • Sprint Review: 4 hours.

      • Sprint Retrospective: 3 hours.

    • All events (rituals/ceremonies) are time boxed. A time box is a previously agreed period of time during which a person or a team works steadily towards completion of some goal. There is a maximum amount of time allocated to the events.

    • Rather than allow work to continue until the goal is reached, and evaluating the time taken, the time box approach consists of stopping work when the time limit is reached and evaluating what was accomplished.

    • The critical rule of time boxed work is that work should stop at the end of the time box, and review progress: has the goal been met, or partially met if it included multiple tasks?

  • Let’s Review

    • Sprint Planning

    • Sprint Backlog

    • Daily Standup

    • Sprint Review

    • Sprint Retrospective

  • Scrum Process Review

    • Scrum Roles

      • Scrum Team

      • Product Owner

      • Scrum Master

    • Key Artifacts

      • Product Backlog

        • Requirements - user stories

        • Desired work

        • Prioritized by Product Owner

        • Anybody can add to it

      • Sprint Goal

        • Summary of work focus in Sprint

        • Declared by Product Owner

        • Accepted by team

      • Sprint Backlog

        • Team member chooses work - work never assigned

        • Owned/managed by team

        • Estimated work remaining updated daily.

      • Block List

        • List of blocks or unmade decisions.

        • Owned by Scrum Master

        • Updated Daily.

      • Burndown Chart

        • Shows effort spent over period.

        • Stories/features complete.

    • Ceremonies

      • Sprint Planning

        • Hosted by Scrum Master.

        • Highest priority items from Product Backlog become Sprint Backlog.

        • Estimate Sprint Backlog by effort.

        • Work Breakdown.

        • Declare Sprint Goal.

      • Daily Standup/Daily Scrum

        • Hosted by Scrum Master

        • 15 mins - same time each day.

        • Not for problem solving.

          • 1) What did you do?

            • 2) What will you do?

            • 3) What's in your way?

        • Team updates sprint backlog.

      • Sprint Review

        • Hosted by Scrum Master 2-4 Hours

        • Accomplishments.

        • Entire team participates.

        • Features demoed for feedback.

      • Sprint Retrospective

        • Hosted by Scrum Master 15-30 mins

        • Discussions on What to "start doing", "continue doing", "stop doing".

PreviousQuiz 6NextQuiz 7

Last updated