Of all the Scrum ceremonies, Sprint Planning and the Daily Scrum are the ones most likely to be misunderstood — and, as a consequence, most likely to be dreaded. "Planning" becomes a 4-hour estimation argument. "Daily" becomes a 45-minute status report to management.
This lesson explains what these ceremonies are supposed to be, and gives you the tools to recognize when they've drifted.
Learning Objectives
By the end of this lesson you will be able to:
- Describe the two parts of Sprint Planning and their outcomes
- Explain the purpose of the Daily Scrum and what it is NOT
- Identify at least two warning signs that each ceremony has gone wrong
- Describe a QA engineer's specific contributions to both ceremonies
Sprint Planning: Building the Game Plan
Sprint Planning is the ceremony that opens every sprint. Its purpose is to answer two questions:
Part 1 — "Why is this sprint valuable?" The Product Owner presents the highest-priority backlog items and proposes a Sprint Goal. The team discusses and commits to that goal (or negotiates it if they think it's unrealistic).
Part 2 — "What can we do this sprint?" and "How will we do it?" The team selects backlog items from the top of the Product Backlog — as many as they confidently believe they can complete — and breaks them into tasks. By the end of planning, the Sprint Backlog exists.
Time-box: Up to 8 hours for a 4-week sprint (proportionally shorter for shorter sprints).
The QA Engineer's Role in Sprint Planning
Sprint Planning is not a developer-only meeting. QA has specific, high-value contributions:
Reviewing Acceptance Criteria: Before a story gets pulled into a sprint, it should have acceptance criteria. QA engineers are often the best people to stress-test those criteria: "What happens if the user enters an empty string? What happens if the network drops mid-request?" These questions catch gaps before they become bugs.
Providing Testing Estimates: QA work is development work. If a story requires 3 days of coding and 1 day of testing, the sprint capacity calculation must include that testing day. A team that plans without accounting for QA time will consistently overcommit.
Flagging Testability Issues: Some stories are well-written from a business perspective but impossible to test as described. "The system should be fast" is not testable. Sprint Planning is the right moment to flag this — not after the feature is built.
The Daily Scrum: 15 Minutes of Synchronization
The Daily Scrum is a 15-minute event held every day of the sprint, at the same time and place. Its purpose is for the Development team (including QA) to synchronize activity and adapt the sprint plan if needed.
The classic three questions:
- What did I do yesterday that helped the team meet the Sprint Goal?
- What will I do today to help the team meet the Sprint Goal?
- Do I see any impediment that would prevent me or the team from meeting the Sprint Goal?
The time-box is not a suggestion. If a topic needs more than 15 minutes, it gets scheduled as a separate conversation after the standup — not during it.
What the Daily Scrum Is NOT
- Not a status report to management. The Scrum Master and management might attend, but the conversation is team-to-team, not team-to-boss. If developers change their answers based on who's watching, the standup has been corrupted.
- Not a problem-solving session. "Our API is returning 500 errors" → "Let's debug it right now" is wrong. The right move: flag the impediment, identify who will resolve it after the standup, and move on.
- Not a task update meeting. "I moved ticket QA-342 to In Progress" is noise. "I'm blocked waiting for the staging deployment — it's delaying test execution for the login story" is signal.
QA in the Daily Scrum
QA engineers often have the most valuable perspective on sprint health:
- "I tested the search feature yesterday — found 2 bugs, logged in Jira, shared with the dev"
- "Today I'm starting on the payment flow — are the staging credentials still valid?"
- "I'm blocked: the feature I'm supposed to test hasn't been deployed to staging yet"
The last example is an impediment. The Scrum Master should pick it up and resolve it — not as a criticism of the developer, but as a workflow problem to fix.
Warning Signs: When These Ceremonies Break
Sprint Planning gone wrong:
- Planning takes 6+ hours for a 2-week sprint
- Stories are pulled into the sprint without acceptance criteria
- QA is not present (or present but not participating)
- The Sprint Goal is "complete all stories in the backlog" (not a goal — a task list)
Daily Scrum gone wrong:
- The standup consistently runs 30+ minutes
- People address the Scrum Master or manager instead of each other
- No one mentions blockers (everyone is afraid to admit they're stuck)
- The same blockers appear day after day without resolution
Pro Tips
The best question you can ask during Sprint Planning: "How will we know this story is done?" If the acceptance criteria can't answer that clearly, the story isn't ready to be in the sprint.
If someone says "the Daily Scrum is useless, let's cancel it" — that's a symptom, not a solution. The meeting became useless because it was misused. Fix the ceremony; don't eliminate it.
Summary
- Sprint Planning creates the Sprint Backlog and Sprint Goal. It has two parts: why is this sprint valuable, and what/how will we build.
- QA contributes to Sprint Planning by reviewing ACs, providing test estimates, and flagging untestable stories.
- The Daily Scrum is a 15-minute team synchronization — NOT a status report to management.
- Warning signs: planning that drags on, standups that become status meetings, blockers that never get resolved.
- A QA engineer's Daily Scrum updates should reflect sprint health: what was tested, what's blocked, what's at risk.