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:
Inspect progress toward the Sprint Goal and make adaptations to the Sprint Backlog or the Sprint Goal, if needed.
Identify any impediments or roadblocks that are preventing the team from meeting their commitments or achieving the Sprint Goal.
Provide an opportunity for team members to share updates on their work and discuss any dependencies or overlaps with other team members.
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:
The meeting should be held at the same time and place every day.
The meeting should be timeboxed to 15 minutes or less.
The Development Team should attend and participate.
The Scrum Master should facilitate the meeting.
The Product Owner and stakeholders can attend but should only listen and not interrupt.
Each team member should answer three questions:
What did you do yesterday?
What will you do today?
Are there any obstacles or impediments in your way?
The meeting is not a status update or problem-solving session, but a coordination and planning session for the Development Team.
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".
Last updated
