Scrum Events Are Necessary (And Not Evil)

By: David Hawks | Nov 30, 2016 |  Article,  Scrum,  ScrumMaster

Example Scrum events - Refs gather for a quick meeting

In Scrum, there exists a general confusion about the Scrum events or meetings: when they happen, who attends and why they exist.

The last question comes up…a lot. There will be resistance to “all the overhead” of Scrum, meetings included. In order to convince others to participate in Scrum events, you can’t just say, “those are the rules of Scrum.” Developers and managers need to be convinced, which means we Agilists need to make sure they understand the value. Here are the Scrum events and a quick explanation of why they exist.

Backlog Grooming

When: During Sprint

How Long: 1 hrs per week of the Sprint

Who attends: PO, Dev team, SM and optionally key SME stakeholder

Input: Updated product backlog

Output: Fully estimated backlog, 2-3 sprints worth of sprintable stories, action items needed to prepare for next sprint

Purpose: Prepare the backlog for upcoming Sprints (estimates, partner with PO to breakdown stories, determine what needs to be done to be ready to start work)

Impact of not doing: Team has to create Sprint plan without full understanding of the work to be done

Symptoms of poor Backlog Grooming: Team not ready to plan, resistance to commit during Sprint planning due to lack of understanding, risky sprint plan


Sprint Planning

When: Beginning of Sprint

How Long: Approximately 2 hours per week of your Sprint

Attendants: Product Owner, Development Team and ScrumMaster

Input: Prioritized Product Backlog with  at least 2 Sprints of “Ready” Stories

Output: Sprint Backlog

Purpose: For the team to develop a Shared Understanding and Shared Commitment of What(Scope) and How (Plan)

What would be the impact of not doing it? If the team starts building without alignment on scope and plan, then this will most likely lead to rework later. Also, investing this time hould help to reduce later meetings, allowing the team to just sync 15 minutes each day.

Symptoms of poor Sprint Planning: Carryover at the end of the Sprint, long Daily Scrums, surprises during the Sprint


Daily Scrum

When: Daily

How Long: 15 minutes

Who attends: Dev Team, SM, PO

Input: Updated Task Board and Burndown chart

Output: Days-worth of tasks for each team member, blockers and impediments preventing team from making progress, questions

Purpose: To create a plan of attack for the day and stay aligned

What’s the impact of not doing: Risks may arise causing the team to fail the Sprint, frustrations when not having visibility into progress of other team members

Symptoms of poor Daily Scrum: Issues arise and aren’t resolved quickly, poor collaboration across team members


Sprint Review

When: End of the Sprint

How Long: 30-60 Minutes

Who Attends: Stakeholders, Dev Team, PO, SM

Input: Potentially Shippable Product Increment of “Done-Done” Stories

Output: Feedback incorporated as a new story on the backlog

Purpose: To gather feedback and/or validation from stakeholders on product

What’s the impact of not doing: Late feedback from stakeholders will lead to expensive rework late in the release cycle

Symptoms of poor Sprint Review: No stakeholders present or silent, Long UAT later, Rework of features post release


Sprint Retrospective

When: End of Sprint

How Long: 90 minutes

Who Attends: SM, Dev Team, PO – Only

Input: Results of Sprint (Burndown)

Output: Action plan for improvement

Purpose: Determine ways for the team to improve their process and team

Impact of not doing: Team never becomes high performing

Symptoms of poor Sprint Retro: No big improvements are ever implemented, team is constantly frustrated, no improvement realized


If you are still having trouble convincing the team of the value of Scrum events, there may be other issues at play. One reason developers don’t see the value in these meetings is that they are still working in silos and not as a team. In that case, it may be time to restructure from component teams to feature teams, physically move the individuals into working pods, and to re-kickoff teams.

This is the first of a two-part blog series on Scrum events. The next blog post in the series– a practical guide for scheduling Scrum events.


Leave a Reply

Your email address will not be published. Required fields are marked *

< Back