Standard Operating Procedure: Agile Sprint Planning SOP

Standard Operating Procedure: Agile Sprint Planning

1. Executive Summary & Purpose

This SOP defines the standardized execution of Sprint Planning at Template Registry. The objective is to align the engineering team on scope, velocity, and technical implementation for a defined delivery cycle. This procedure ensures high-fidelity backlog grooming, realistic capacity planning, and transparent ownership.

2. Scope & Prerequisites

• Scope: Applies to all engineering, product, and QA personnel involved in sprint delivery.
• Tools: Jira (or equivalent ALM), Confluence, Slack, GitHub.
• Prerequisites:
  • Backlog must be groomed (Refined) to "Ready for Development" status.
  • Velocity data for the past three sprints must be available.
  • Resource availability (PTO/holidays) must be updated in the resource calendar.

3. Roles & Responsibilities (RACI)

4. Step-by-Step Procedure

Phase I: Pre-Planning Validation

• Verify Jira backlog contains at least 1.5x the projected velocity of "Ready" stories.
• Confirm all ticket dependencies are mapped and flagged.
• Ensure definitions of "Ready" and "Done" are accessible to all participants.

Phase II: The Planning Session (Execution)

• Capacity Setting: Calculate team capacity by subtracting PTO and estimated overhead (meetings/unplanned support) from total man-hours.
• Priority Selection: Product Manager presents the top-priority items; Engineering team validates technical feasibility.
• Commitment: Team pulls stories from the top of the backlog until capacity is met.
• Task Breakdown: Team decomposes stories into sub-tasks (Frontend, Backend, QA, Documentation).
• Confidence Check: Conduct a "Fist-to-Five" vote on the commitment; any score below 3 requires immediate re-negotiation of scope.

Phase III: Post-Planning Closure

• Set Sprint Goal in Jira.
• Confirm Sprint duration and dates.
• Send summary email/Slack notification to stakeholders with scope commitment.

5. Quality Assurance & Pro-Tips

• Avoid "Feature Creep": If the scope changes during planning, a ticket must be removed to maintain the velocity baseline.
• Capacity Buffer: Always reserve 15-20% of capacity for unplanned technical debt or production support.
• Metric Threshold: If the team consistently exceeds capacity by >10% or fails to meet the commitment, re-evaluate Story Point calculation methods.
• Pro-Tip: Focus on the Sprint Goal over individual tickets. If a story does not contribute to the goal, question its inclusion.

6. Frequently Asked Questions

Q: What should we do if we cannot reach a consensus on story points? A: Utilize the "High-Low" technique. The team members with the highest and lowest estimates explain their reasoning. Re-vote once. If still split, default to the higher estimate to maintain buffer.

Q: Can we add tickets to the sprint after planning has concluded? A: Strictly discouraged. Any mid-sprint additions require an equivalent removal of scope (1:1 trade) to prevent velocity inflation and burnout.

End of Document. Authored by Julian Vance, Chief Architect.