1.2Sprint Planning

Sprint planning is where the team decides what work to commit to for the sprint. This is one of the highest-leverage moments for QA.

What QA Contributes

• Ask clarifying questions about acceptance criteria: "What should happen if the user enters an emoji in the name field?" often reveals undefined behavior that would otherwise become a bug.
• Identify testing dependencies early: Test data needs, environment setup, third-party service access, test accounts.
• Flag stories that require disproportionate testing effort: A "2-point" story that needs testing across 3 browsers, 2 APIs, and 4 user roles is actually a 5-point effort.
• Suggest splitting large stories: "Can we split this into 'basic checkout' and 'checkout with coupons' so we can test and ship incrementally?"
• Advocate for test infrastructure stories: "We need a story for fixing the 8 flaky tests from last sprint" should be a legitimate backlog item.

Common Planning Mistakes

Mistake	Impact	Fix
Testing effort not included in estimates	QA becomes the bottleneck at sprint end	Include testing in every story estimate
Stories without acceptance criteria	QA guesses what to test, misses requirements	Require acceptance criteria before pulling into sprint
No QA capacity reserved for tech debt	Flaky tests and infrastructure rot accumulate	Reserve 10-20% of sprint capacity for QA improvements
QA not invited to planning	Testing surprises emerge mid-sprint	QA is a required attendee, not optional