Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

How leaders can effectively support and leverage the Scrum Events

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Continuing the Scrum Guide companion for Leaders Series

This is post 4 (out of 5) in the series:

  1. What Scrum means for Leaders.
  2. How to create the conditions for success using the Scrum Values.
  3. Scrum Roles/Accountabilities and how the Leader can serve the Scrum roles and the organization effectively.

In this post, we will talk about the Scrum Events. Leaders should understand and serve the Scrum Events. Serving their teams can mean participating in an event and providing feedback. It means creating the conditions for a successful event (without participating or sometimes even BY not participating). Leaders also serve their teams and stakeholders by consolidating/eliminating non-Scrum events when there’s duplication/redundancy.

The Sprint

This is the fundamental structure that all work is done within. Sprints enable predictability and empiricism. Leaders should help their teams balance the risk of a long Sprint Horizon with the overhead and stress of too-short Sprints. During the Sprint Leaders help protect the team from distractions. 

Sprint Planning

Sprint Planning is where the Scrum Team collaboratively plans their Sprint based on priorities set by the Product Owner. The Scrum Team discusses 3 topics – Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done? The Scrum Team commits to a Sprint Goal and provides a Sprint Forecast. 

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

As Stakeholders, Leaders don’t usually participate in Sprint Planning (unless they are also members of the Scrum Team). They are welcome to work with the Product Owner to influence the direction of the Scrum Team while supporting the Product Owner’s vision and Product Goal before and after Sprint Planning. 

Leaders use the transparency of the Sprint Goal and Sprint Backlog to gain an understanding of where the Scrum Team is focusing and what to expect to see in the Sprint Review. They should avoid diving into the details of the Sprint unless the Scrum Team asks for help. Often Leaders find it hard to leave the Scrum Team to work as they see fit and often ‘offer’ help. Help can be perceived as managing the Scrum Team, which ultimately will discourage self-management. 

The Sprint Plan is a forecast provided by the Scrum Team. There is a tendency to assume this commitment is then used to judge the Scrum Team. Leaders should avoid this, as the more complex the work the more uncertainty exists. The commitment is for the Scrum Team to do their best to deliver the Sprint Goal, or to learn if this goal is unachievable.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is a 15-minute event for the Developers of the Scrum Team … If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. 

Leaders generally don’t participate in the Daily Scrum. Any participants that aren’t involved in the work of the Sprint are considered a distraction. The people doing the work should focus on the work and solving problems rather than providing status updates or posturing. Leaders should help the Scrum Team with removing impediments rising out of the Daily Scrum that require their involvement. 

Sprint Review

The purpose of the Sprint Review 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.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The success of a Sprint Review is determined by who’s there and how they show up. Leaders can help the Scrum Team get the right people to the Sprint Review and coach stakeholders in what’s the effective way to behave in this very valuable opportunity to Inspect and Adapt the direction of the Scrum Team and the Product. 

In some cases, the Leader will also be a real stakeholder themselves and this can provide them with the key opportunity to inspect how the team is doing and engage with them directly. This is also an opportunity to demonstrate the values that Scrum encourages such as Openness and Respect. 

Leaders have a role in making sure that Stakeholders understand the scope of their influence in the Sprint Review and the fact that it is a feedback meeting not a status meeting for the Stakeholders. The Product Owner might (or might not) adapt the Product Backlog based on the discussion in the Sprint Review. Leaders might need to coach Stakeholders on this new way of working or might partner with the Scrum Master and create the conditions where the Scrum Master can coach the Stakeholders.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

While the Leader doesn’t participate in the Sprint Retrospective they can serve the Scrum Team by helping them implement improvements that span beyond the Team’s scope of control or even owning such improvements. The Leader can create an environment of continuous improvement that will encourage the Scrum Team to invest in improving how they work. 

 

The Leader’s role in the Scrum Events

While Leaders aren’t mentioned explicitly they can serve their teams by creating the environment in which effective Scrum events take place, with the right people and the right mindset. Without the Empiricism enabled by Transparency, Inspection and Adaptation on Scrum events, Scrum is but just a mechanistic theater.

  • Leaders enable the team to have a Sprint Planning event in which they are empowered to figure out a realistic and sustainable Sprint Goal. They gain an understanding of direction via the Sprint Goal. This enables them to communicate with other stakeholders about the work of the team. (as they might be expected to do).
  • Leaders don’t participate in Daily Scrum and don’t need to actively inquire about what takes place in them either. The Scrum Team will reach out to the Leader if there’s an impediment that requires their involvement.
  • Leaders can participate in the Sprint Review as a Stakeholder, gain visibility to where the Product is based on the Increment, and provide feedback that will be considered by the Team and the Product Owner (but not necessarily adopted as such). They have even a bigger role in enabling an effective Sprint Review by working with other Stakeholders to create an environment of empiricism and respect/self-management.
  • Leaders serve their teams by helping them implement improvements that span beyond the team’s scope of control. They might take ownership of such improvements. They create the cultural conditions where continuous improvement work is a first-class citizen in the organization’s work plans and capacity allocations.

In addition, Leaders should look at other events they’re asking members of the Scrum Team to participate in and experiment with how to minimize waste and duplication. Classic Status Meetings could be replaced more effectively by Sprint Reviews for example.

In our final chapter of the series, we will turn to the Leader’s role in enabling empiricism via the Scrum Artifacts.

 

 

Subscribe for Email Updates:

Categories:

Tags:

A Kanban System for Software Engineering
Nexus vs SAFe
Risk Management in Kanban
WIP
Business Agility
Elastic Leadership
Lean Agile Basics
SAFe DevOps
Agile Project
Jira Cloud
Agile
Perfection Game
Tools
Lean Agile Management
Introduction to ATDD
Rovo
LPM
Scrum
Software Development
Enterprise DevOps
Value Streams
chatgpt
Software Development Estimation
Managing Risk on Agile Projects
Large Scale Scrum
Certification
Hybrid Work
Engineering Practices
Effective Agile Retrospectives
Acceptance Test-Driven Development
Sprint Retrospectives
Advanced Roadmaps
ATDD vs. BDD
Lean-Agile Software Development
ATDD
Agile Development
Agile Product Development
ART Success
BDD
Professional Scrum with Kanban
Product Management
Scrum.org
Scrum Master Role
Jira Plans
System Team
Coaching Agile Teams
Continuous Integration
Professional Scrum Product Owner
Legacy Enterprise
Agile Release Planning
Risk-aware Product Development
Risk Management on Agile Projects
Nexus
Jira
Continuous Planning
ROI
Lean and Agile Techniques
Program Increment
Agile Testing Practices
Keith Sawyer
Agile Israel
Operational Value Stream
Agile Release Management
Agile Techniques
Retrospectives
Continuous Deployment
Built-In Quality
Agile Project Management
Agile Marketing
Scrum Master
Rapid RTC
Product Ownership
Confluence
Achieve Business Agility
Agile Games and Exercises
Lean Agile
Systems Thinking
RTE Role
Continuous Improvement
predictability
Continuous Delivery
Lean Software Development
Test Driven Development
Implementing SAFe
Games and Exercises
Agile Exercises
lean agile change management
PI Objectives
Managing Projects
Scrum Values
Agile Risk Management
Implementation of Lean and Agile
Story Slicing
speed at scale
EOS®
Scrum With Kanban
Release Train Engineer
Scrum and XP
QA
Agile for Embedded Systems
Atlaassian
RSA
Video
Lean and Agile Principles and Practices
SA
Agility
Sprint Planning
Process Improvement
The Kanban Method
Change Management
Pomodoro Technique
Presentation
AgileSparks
Agile in the Enterprise
Releases Using Lean
ARTs
Legacy Code
Agile Contracts Best Practices
What Is Kanban
Lean Agile Leadership
Slides
Agile Games
Kaizen
PI Planning
TDD
AI
Webinar
Kanban Game
Code
Limiting Work in Progress
Manage Budget Creation
Agile Mindset
Agile Community
speed @ scale
Artificial Intelligence
Nexus Integration Team
Covid19
An Appreciative Retrospective
Principles of Lean-Agile Leadership
SAFe
NIT
Development Value Streams
User stories
Introduction to Test Driven Development
SAFe Release Planning
Professional Scrum Master
System Archetypes
Nexus and Kanban
Applying Agile Methodology
Agile Israel Events
SPC
AI Artificial Intelligence
Team Flow
Lean-Agile Budgeting
Agile Basics
Accelerate Value Delivery At Scale
ScrumMaster Tales
LeSS
Portfolio for Jira
LAB
Scaled Agile Framework
Agile Program
Agile Outsourcing
Frameworks
Sprint Iteration
Lean Risk Management
Kaizen Workshop
ALM Tools
Agile Assembly Architecture
Agile Product Ownership
Iterative Incremental Development
Nexus and SAFe
Lean Startup
Scrum Primer
Kanban Basics
Quality Assurance
Agile Delivery
System Integration Environments
Lean Agile Organization
Kanban 101
Kanban
Jira admin
transformation
DevOps
Spotify
The Agile Coach
Self-organization
Entrepreneurial Operating System®
POPM
Tips
Certified SAFe
Daily Scrum
Agile and DevOps Journey
Scrum Guide
Amdocs
Reading List
Lean Budgeting
Planning
IT Operations
RTE
GanttBan
Agile India
agileisrael
Atlassian
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart