CHC5056 Innovative Product Development · Semester 1, Week 7

Sprint Planning
and Daily Scrum

How does a Scrum Team plan a realistic Sprint and steer it every day?
Product Owner ordered the Canteen App backlog in Week 6.On Monday morning of Sprint 1, the team still must decide how much to pull and what counts as finished.
Session45 minutes
Running caseCanteen Pre-order App
Followed byWeek 8: Review and Retrospective
Learning outcomes

Four Things You Will Be Able to Do

01
Distinguish Product Goal, Sprint Goal and Definition of Done, and write a Sprint Goal that states value and focus without listing every task.
Sprint Reviews (Part D)
and Class Test
02
Forecast realistic Sprint scope using priority, Definition of Done, team capacity, availability and dependencies.
Sprint Reviews (Part D)
and Group Presentation
03
Decompose selected Product Backlog Items into an actionable Sprint Backlog owned by Developers.
Team project evidence
for Group Presentation
04
Diagnose a weak Daily Scrum and adapt the Sprint Backlog toward the Sprint Goal when blockers or delays arise.
Sprint Reviews (Part D)
and Class Test
Learning outcomes · 0 to 1 min
Opening and retrieval · Fictional teaching case

Monday Morning of Sprint 1: Why a Backlog Alone Is Not Enough

Day 1 Morning

Six items pulled at once

Everyone grabs stories from the top of the backlog without checking coursework labs or what "finished" means.

Days 1 to 3

Coding in silence

The canteen manager has not sent the menu CSV, yet nobody raises the delay or adjusts the plan.

Day 4 Afternoon

Nothing integrates

Half-built screens sit on separate laptops. Zero features pass testing on a phone.

Ask: What two checks were missing before they started coding?

Story first
Fictional teaching case
Opening and retrieval · 1 to 5 min
Commitments · Moved from Week 6

What "Finished" and "Focused" Mean: The Three Commitments

Each Week 6 Scrum artefact pairs with one Week 7 commitment Product Backlog pairs with Product Goal for long-term direction. Sprint Backlog pairs with Sprint Goal for a single Sprint objective. Increment pairs with Definition of Done as a shared quality gate. ARTEFACT 01 (WEEK 6) Product Backlog Ordered list of possible work. ACCOUNTABLE: PRODUCT OWNER COMMITMENT 01 Product Goal Long-term direction: Let campus students pre-order lunch and skip the queue. DIRECTION ARTEFACT 02 (WEEK 6) Sprint Backlog Selected items plus delivery plan. ACCOUNTABLE: DEVELOPERS COMMITMENT 02 Sprint Goal Single Sprint objective: Book a pick-up slot and view today's available dishes. FOCUS ARTEFACT 03 (WEEK 6) Increment Working step a user can try. ACCOUNTABLE: DEVELOPERS COMMITMENT 03 Definition of Done Shared quality gate: Merged, peer-reviewed, passes all checks on a test phone. QUALITY GATE SPRINT PLANNING DURING SPRINT
Text version of the diagram

Product Backlog pairs with Product Goal, giving long-term direction. Sprint Backlog pairs with Sprint Goal, giving a single objective for this Sprint. Increment pairs with Definition of Done, setting the shared quality check every finished item must pass.

Commitments and Planning · 5 to 15 min
Sprint Planning · Three topics

Sprint Planning Topics 1 and 2: Why Valuable, What Can Be Done

The three topics of Sprint Planning in sequence Topic 1 asks why the Sprint is valuable and produces the Sprint Goal with the whole Scrum Team. Topic 2 asks what can be done using priority, capacity, dependencies and Definition of Done to create a realistic forecast. Topic 3 asks how chosen work gets done, owned solely by the Developers as the Sprint Backlog. TOPIC 01 · WHY Why is this Sprint valuable? Connect Product Goal to user value. Focus on essentials, avoid wasted work. OUTPUT: SPRINT GOAL WHO: Whole Scrum Team TOPIC 02 · WHAT What can be Done this Sprint? Check Priority + Capacity + Availability + Dependencies + Definition of Done. OUTPUT: FORECAST (PBIS) WHO: Developers + Product Owner TOPIC 03 · HOW How will chosen work get done? Decompose selected items into actionable tasks (under 1 day each). OUTPUT: SPRINT BACKLOG WHO: Developers only
Text version of the diagram

Sprint Planning answers three topics in sequence. Topic 1 (Why): the whole Scrum Team agrees why this Sprint is valuable, producing the Sprint Goal. Topic 2 (What): Developers and the Product Owner select a realistic Forecast using priority, capacity, dependencies and Definition of Done. Topic 3 (How): Developers alone decompose the selected work into an actionable Sprint Backlog.

Commitments and Planning · 5 to 15 min
Sprint Planning · Topic 1

Weak vs Strong Sprint Goal: Focus on Essentials

Weak · Task-list goal
“Complete Stories 1, 2, 3 and 4 by Friday.”
Gives no focus if one story hits a blocker. Treats every task as equally urgent and invites cut corners just to tick boxes.
Strong · Outcome-oriented Sprint Goal
“Allow students to select a pick-up slot and see available dishes to complete a basic pre-order.”
States user value and gives coherence. When a surprise hits on Day 4, the team knows which parts protect the outcome.
Focus rule (lean principle): concentrate on essentials that pass the Definition of Done, and avoid wasted work on unrequested extras.
Commitments and Planning · 5 to 15 min
Sprint Planning · Topic 2

Capacity, Availability and Dependencies: Why 100% Booking Breaks

Over-committed 100% capacity plan compared against a realistic forecast with buffer Plan A books all 10 available person-days with 13 points of features; a Day 3 dependency delay pushes testing out so zero items pass Definition of Done. Plan B books 7.5 days for core goal work, 1.5 days buffer for dependency and learning risk, and 1.0 day for testing and merge, achieving the Sprint Goal. PLAN A · OVER-COMMITTED (100% BOOKED ON FEATURES, 13 PTS PULLED) 0 ITEMS PASS DEFINITION OF DONE Feature coding packed tight (Days 1 to 3) Day 3 Collision Menu CSV delay + QR bug Merge & testing squeezed out No buffer for exams, unknowns or integration. Half-finished stories fail the quality gate. PLAN B · REALISTIC FORECAST (8 PTS CORE + EXPLICIT CONTINGENCY) SPRINT GOAL ACHIEVED Core Sprint Goal stories (7.5 person-days) Risk & Dependency Buffer (1.5 d) DoD Checks & Merge (1.0 d) Accounts for actual lab availability, external dependencies and Definition of Done time.
Text version of the diagram

Plan A books all 10 available person-days with 13 points of features; a Day 3 menu CSV delay and QR bug push testing out, leaving zero items meeting Definition of Done. Plan B commits 8 core points across 7.5 days, reserves 1.5 days buffer for dependency and QR risk, and keeps 1.0 day for Definition of Done checks and merge, achieving the Sprint Goal.

Forecast, not quota: capacity is a team reality check, not a target to punish individuals. Leave room for integration and unknowns.
Commitments and Planning · 5 to 15 min
Sprint Planning · Topic 3

Sprint Planning Topic 3: Developers Own the Sprint Backlog

Part 01 · Why

Sprint Goal

The single objective that explains why this Sprint matters to campus users.

Stays stable for focus
Part 02 · What

Selected Backlog Items

The Product Backlog Items pulled into the Sprint Forecast with the Product Owner.

Renegotiated with Product Owner if needed
Part 03 · How

Actionable Delivery Plan

Concrete tasks under one day each, owned and updated daily by Developers.

Adapts every day
Ownership boundary: neither the Product Owner nor the Scrum Master assigns tasks. Developers plan how to hit the Sprint Goal and adapt tasks as new facts emerge.
Sprint Backlog and Daily Scrum · 15 to 25 min
Daily Scrum · Inspection and adaptation

Daily Scrum: 15 Minutes to Inspect Goal Progress, Not Report Status

Daily Scrum peer inspection topology and 24-hour adaptation loop Wrong topology: Developers report status one-way to the Scrum Master or Product Owner. Right topology: Developers inspect progress together toward the Sprint Goal. In the 24-hour loop, the 15-minute Daily Scrum adapts the Sprint Backlog and surfaces impediments for follow-up outside the meeting. STATUS REPORT (WRONG) Developer 1 Developer 2 Developer 3 Scrum Master or Product Owner (Boss) TEAM INSPECTION (RIGHT) Developer 1 Developer 2 Developer 3 Sprint Goal Are we on track? 24-HOUR INSPECTION AND ADAPTATION LOOP Sprint Backlog Actionable plan for the next 24 hours Daily Scrum (15 min max) Inspect progress toward Sprint Goal; any format that works Inspect Adapt plan Impediment Follow-up (After the 15-min meeting) Raise blockers here; solve technical details outside the timebox
Text version of the diagram

Wrong topology: Developers report status to the Scrum Master or Product Owner as a boss. Right topology: Developers connect with one another and inspect progress toward the Sprint Goal. Every 24 hours, the 15-minute Daily Scrum inspects and adapts the Sprint Backlog. Any Impediment surfaced in the meeting is resolved afterwards outside the 15-minute timebox.

Sprint Backlog and Daily Scrum · 15 to 25 min
Daily Scrum · Fictional teaching case

Poor Daily Scrum vs Goal-Centred Daily Scrum

Poor · Reporting status to the Scrum Master
Developer 1 (to Scrum Master)“Yesterday I styled the buttons. Today I will keep working on CSS. No blockers.”
Developer 2 (to Scrum Master)“Yesterday I waited for the menu CSV. Today I will start the favourite-meal feature instead.”
Developer 3 (to Scrum Master)“I finished my part. Tell me what else to code next, Scrum Master.”
Why it fails: turns the Scrum Master into a manager, drops the Sprint Goal, and lets Developer 2 jump to a low-priority extra.
Goal-centred · Inspecting the Sprint Goal
Developer 2 (to team)“Still no menu CSV from the canteen, so our menu view is blocked and our Sprint Goal is at risk.”
Developer 3“Let's build a 5-dish sample stub together today so pick-up booking still works end to end.”
Developer 1 (to Scrum Master & team)“I will wire the slot picker to the stub. Scrum Master, please follow up with the canteen manager after this call.”
Why it works: surfaces risk early, adapts today's plan inside 15 minutes, and moves blocker follow-up outside the meeting.
Fictional teaching case · Day 4
Sprint Backlog and Daily Scrum · 15 to 25 min
Worked example · Fictional teaching case

Canteen App Sprint 1: Ten Person-Days, Thirteen Points

OrderBacklog itemPtsRisk or dependency
01 Choose pick-up time slot 5 Core value
Uses static slot data
02 View today's canteen menu 3 External dependency
Canteen CSV due Day 2
03 Generate QR pick-up receipt 3 Unfamiliar tech
First time using QR library
04 Save favourite meal 2 Nice to have
Not needed for first order
Team Constraints

10 available person-days

5 classmates over a 5-day simulation Sprint, after subtracting lab sessions and the Product Owner's user interviews.

Definition of Done
Code merged to main branch
Peer-reviewed by one teammate
Passes all Given/When/Then checks
Runs cleanly on a test phone
Pause and calculate: which items belong in Sprint 1, and what happens if the CSV slips on Day 4?
Worked example · 25 to 35 min
Worked example · Decision and adaptation

Justify the Forecast, Then Adapt on Day 4

Question 01

Realistic Forecast

How many points should the team pull into Sprint 1, and which item stays out?

Question 02

Outcome Sprint Goal

How do we state value for students without writing a shopping list of stories?

Question 03

Day 4 Adaptation

If the canteen CSV still has not arrived by Day 4, how do Developers protect the goal?

Discuss your answers to the three questions first. Reveal the reference reasoning only after students propose a selection and Day 4 response.

Forecast
Select 8 points (Items 1 and 2, or 1 and 3). Leave Item 4 (Save favourite meal) in the Product Backlog to preserve buffer for the CSV dependency, QR learning and Definition of Done checks.
Sprint Goal
“Allow students to select a pick-up slot and see available dishes so they can complete a basic pre-order.” States one coherent user outcome.
Day 4 Daily Scrum
Use a 5-dish sample menu stub so the pick-up flow passes Definition of Done end to end, and ask the Scrum Master to follow up with the canteen manager after the 15-minute meeting.
Worked example · 25 to 35 min
Guided application · 7 minutes

Activity: Fix the Sprint Plan and the Daily Scrum

Flawed Sprint 1 Plan to Repair
Weak Sprint Goal

“Complete Stories 1, 2, 3 and 4 by Friday.”

Forecast Choice

All 13 points loaded into 10 available person-days.

Poor Daily Scrum Snippet

“Yesterday I styled buttons. Today I will keep coding. No blockers. Is that okay, Scrum Master?”

01Rewrite the weak Sprint Goal so it states clear user value and focus.
02Pick a realistic forecast from the 13-point table and state one buffer reason.
03Propose one concrete change to the Daily Scrum conversation.
04 min in pairs03 min class debrief
Guided application · 35 to 42 min
Close

Three Things to Take Away

01

Three commitments anchor the artefacts: Product Goal, Sprint Goal and Definition of Done.

02

Sprint Planning agrees why and what together, while Developers size a realistic forecast and own how.

03

The Daily Scrum inspects progress toward the Sprint Goal in 15 minutes and adapts today's plan.

Exit check: Who owns the Sprint Backlog, and what may change versus what stays stable during a Sprint?
One sentence
on the way out
Exit check and transition · 42 to 45 min
Transition · Seminar and Week 8

From Canteen Case to Your Team Project

This Week's Seminar (2 × 45 min)
Plan Sprint 1 and set up repository transparency.
Bring your team's Product Backlog. Agree your Definition of Done, write your Sprint Goal, forecast real availability, decompose tasks, and practise your branch and pull-request workflow.
Next Week's Lecture (S1 Week 8)
Sprint Review and Sprint Retrospective.
Learn how to inspect a Done Increment with stakeholders for Sprint Reviews (Part D) and Group Presentation, and turn Sprint lessons into one owned improvement action.
Seminar evidence produced this week Sprint Goal · Sprint Backlog · Capacity rationale · Definition of Done · Repository workflow
Exit check and transition · 42 to 45 min

Speaker notes