Sprint planning
#✅ Sprint planning checklist
Checklist for the Phoenix Payments sprint planning meeting on . The team is planning Sprint 24.14, focused on improving checkout reliability, reducing payment errors, and completing monitoring improvements before the next production release.
Preparation | Meeting | Follow up |
|---|---|---|
|
|
|
#👥 Sprint team members
Name | Role |
|---|---|
@unknown | Scrum Master and meeting facilitator |
Priya Shah | Product Owner for Checkout and Payments |
Tom Bennett | Senior Backend Engineer, payment orchestration |
Amelia Clarke | QA Engineer, regression and release validation |
#✏ Sprint planning meeting items
Use this plan to structure the Phoenix Payments Sprint 24.14 planning session, set expectations, and define the backlog for the upcoming two-week sprint. The meeting links planning decisions to current checkout reliability goals and the July production release.
#Agenda
The meeting opens with a short review of Sprint 24.13, followed by capacity planning, risk review, and backlog selection for Sprint 24.14. The team will prioritise work that reduces failed payment retries, improves observability, and protects the checkout conversion rate.
Close Sprint 24.13 and confirm final completed story points.
Review carry-over work: PAY-218 failed retry handling and PAY-224 webhook timeout investigation.
Confirm Sprint 24.14 capacity, holidays, support coverage, and release freeze constraints.
Agree sprint goal: reduce avoidable checkout payment failures and improve incident diagnosis.
Select committed backlog items and assign owners for each story.
Review risks, dependencies, and follow-up actions before closing the meeting.
#Previous sprint summary
Sprint theme | Checkout bug fixes and payment retry stabilisation |
|---|---|
Story points | Committed: 46 points. Pulled in: 5 points. Completed: 43 points. Carry-over: 8 points across two stories. |
Summary | The team resolved the duplicate authorisation bug, shipped improved payment decline messaging, and completed the first version of retry event logging. The webhook timeout investigation remained open because the team needed additional provider logs. |
#Details
Start date | |
|---|---|
End date | |
Sprint theme | Checkout reliability and payment observability |
#Velocity tracking
https://example.atlassian.net/jira/software/projects/PAY/boards/42/reports/velocity: average velocity over the last five sprints is 44 points, with a range of 38 to 51 points.
#Adjusted velocity tracking
https://example.atlassian.net/jira/software/projects/PAY/boards/42/reports/adjusted-velocity: adjusted capacity for Sprint 24.14 is 40 points after accounting for one bank holiday, QA release support, and Tom Bennett being unavailable for two days.
#Capacity planning
Capacity has been adjusted for annual leave, production support commitments, and the planned release validation window. The team should keep at least 15% buffer for unplanned payment provider issues.
Current sprint | Previous sprint | |
|---|---|---|
Total days | 10 working days | 10 working days |
Team capacity | 82% after leave and support rotation | 88% |
Projected capacity | 40 story points | 46 story points committed; 43 completed |
Individual capacity | Jack Graves: 8 facilitation hours; Priya Shah: 4 product review days; Tom Bennett: 6 engineering days; Amelia Clarke: 7 QA days | Jack Graves: 8 facilitation hours; Priya Shah: 5 product review days; Tom Bennett: 8 engineering days; Amelia Clarke: 7 QA days |
#Potential risks
Risk | Mitigation |
|---|---|
Payment provider logs for webhook timeouts may arrive late, delaying PAY-224. | Start with internal timeout tracing and keep PAY-224 below the commitment line until provider evidence is available. |
QA capacity is reduced during release validation in the second week. | Prioritise automated regression coverage early and schedule manual checkout tests before . |
Support escalations may interrupt backend engineering time. | Reserve a 15% sprint buffer and nominate Tom Bennett as first responder only for payment-critical incidents. |
#📚 Sprint planning resources
#Team resources and definitions
Definition of Ready: story has acceptance criteria, dependency notes, analytics impact, and test approach agreed before planning.
Definition of Done: code reviewed, automated tests passing, QA sign-off complete, observability updated, and release notes drafted.