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.
