The document outlines a structured Scrum schedule, detailing key events such as sprint planning, daily scrums, backlog grooming, and sprint retrospectives over a four-week period. It emphasizes the importance of team alignment, backlog prioritization, and the role of the product owner in providing feedback and metrics. Additionally, it highlights the need for time-boxed activities and clear communication to ensure effective collaboration and task management within the Scrum framework.

1. SCRUM EVENTS
What does a healthy scrum
schedule look like?

2. Daily
Stand-up
Customer
Customer
Product Owner

3. What does that
look like?
Week 1
Day 1 Day 2 Day 3 Day 4 Day 5
Week 2
Day 6 Day 7 Day 8 Day 9 Day 10
Sprint
Planning
DemoRetrospective
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum

4. What does that
look like?
Week 1
Day
1
Day
2
Day
3
Day
4
Day
5
Week 2
Day
6
Day
7
Day
8
Day
9
Day
10
Sprint
Planning
DemoRetro.
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Week 3
Day
1
Day
2
Day
3
Day
4
Day
5
Week 4
Day
6
Day
7
Day
8
Day
9
Day
10
Sprint
Planning
DemoRetro.
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Daily
Scrum
Story
Time
Story
Time
Backlog Grooming (PO)

5. P.O. State of
the Union
Team Huddle
Cross Team
Share
Tasking Confirmation
Sprint planning
in Scaled Scrum

6. P.O. State of the
Union
• PO provides a
state of the
product including;
• Next big priorities
• Customer
feedback
• Adoption metrics
Team Huddle
• Teams huddle
together and
define or confirm
that their stories
align with the
State of the union.
(most of the time
they will
• Spokes person
prepares to share
Cross Team Share
• Each team, in turn
shares the stories
they are
forecasting to
complete in the
next iteration
• NOTE: this is a
preliminary
forecast as the
work has not been
tasked out in
detail
• Cross Team
interdependencies
are identified by
the team
presenting
• Cross Team
interdependencies
are identified by
other teams
Tasking
• Teams separate
and define the
detailed tasks
required for each
story.
• This can take a
long time or can
be very quick.
• This is a time-
boxed activity. If
not done by the
end of the time-
box. The teams
need to get
started anyway
Confirmation
• If the list of stories
has changed the
whole team needs
to be informed.
Ideally this is face
to face but may be
on email.
Sprint planning
in Scaled Scrum

7.  Who
 Product Owner(s)
 What
 Review/Prioritize the Product Backlog
 Backlog includes defects
 When
 Continuously
 Output
 A clear prioritized backlog that accurately reflects the
priorities of the Product Owner(s)
Backlog
Grooming

8.  Who
 Product Owners
 BAs
 Scrum Team
 What
 Refinement of the next stories in the queue
 Clarification of the acceptance criteria
 Time for developers to ask any questions
 Split stores that are too large
 Identify spike stories that are too vauge
 When
 A couple of times in the sprint before the stories are due
 Output
 Understanding of the next priority stories
 Written Acceptance Criteria (Given/When/Then)
Story Time

9.  Who
 Active Members: Scrum Team (Dev/QA/Test/UX)
 Passive Members: Product Owner(s)/BAs
 What
 Team Coordination meeting
 NOT a status meeting
 3 Questions
 When
 Daily for 15 minutes only. If you don’t get through it. Stop
anyway
 Output
 Coordination between team members
 Roadblocks that need to be addressed
Daily Standup

10.  Who
 Scrum Team
 May include PO but not necessarily
 What
 Time to Inspect and Adapt
 Kaizen (small incremental improvements)
 When
 After the demo, before planning
 Output
 Tasks for the next sprint with owners and timelines
Sprint
Retrospective

11.  Who
 Scrum Team
 P.O.
 Customers
 Stakeholders etc…
 What
 Demonstrate the work that was completed
 Celebration of the hard work from the last sprint
 Feedback on the final product (note: feedback should have been coming all
along, this is not a surprise meeting.)
 When
 Last day of the sprint
 Output
 P.O. Acceptance of the completed work of the sprint
 Note: Work that does not meet the team’s Definition of Done is not demoed and
is not accepted in that sprint.
Sprint Demo

12. Questions