What is Sprint Planning in AGILE

Standard Operating Procedure: Agile Sprint Planning

1. Executive Summary & Purpose

Sprint Planning is the foundational synchronization event in Agile frameworks (Scrum). The objective is to define the work to be performed during the upcoming iteration (Sprint). This SOP ensures team alignment, capacity-adjusted scope commitment, and clear definition of the "Sprint Goal," minimizing context switching and technical debt accrual.

2. Scope & Prerequisites

• Scope: Applicable to all engineering squads under the Template Registry technical umbrella.
• Prerequisites:
  • Refinement: All selected backlog items must be "Ready" (invest-compliant, estimated, and prioritized).
  • Tools: Jira/Linear (Backlog/Board), Confluence (Sprint Goal documentation), Velocity/Capacity chart.
  • Environment: Synchronous audio/video conferencing or designated war-room.

3. Roles & Responsibilities (RACI)

4. Step-by-Step Procedure

Phase I: Preparation (Pre-Meeting)

• Ensure the Product Backlog is ranked by business value.
• Confirm team availability (PTO, holidays) to calculate net capacity.
• Validate that the top N items in the backlog meet the "Definition of Ready" (DoR).

Phase II: Execution (The Planning Event)

• Define the Sprint Goal: PO presents the objective; team agrees on the business value.
• Select Work: Based on velocity (historical average) and capacity, the team pulls items from the top of the backlog.
• Decomposition: Team breaks down selected User Stories into technical tasks.
• Capacity Check: Re-verify that the total task effort does not exceed the calculated net capacity.
• Commitment: Team formally commits to the Sprint Goal.

Phase III: Closing

• Update the Sprint status to "Active" in the project management tool.
• Ensure all tasks are assigned to owners.
• Broadcast the Sprint Goal to all relevant Stakeholders via the team communication channel.

5. Quality Assurance & Pro-Tips

• Metric Threshold: If the team consistently hits >110% or <80% of their velocity, force a retrospective adjustment of story point calibration.
• Pro-Tip (The 70% Rule): Only plan for 70% of total engineering capacity. Use the remaining 30% for technical debt, unplanned incidents, and operational overhead.
• Pitfall: Avoid "Task Estimation" fatigue. If tasking takes longer than 60 minutes, the User Story was not sufficiently refined. Escalate to the PO for immediate re-refinement.

6. Frequently Asked Questions

Q: Can we change the scope after the Sprint starts? A: Generally, no. Scope changes disrupt the Sprint Goal. If an emergency arises, the PO and team must evaluate if the new task displaces an existing task of equal or greater size. If yes, the displaced task returns to the backlog.

Q: What if we run out of capacity during planning? A: Do not compromise the Definition of Done (DoD). The PO must truncate the backlog at the point capacity is reached. Never over-commit to appease stakeholders; maintain integrity in the commitment.

Q: Who determines if a task is "ready" to pull? A: The Development Team. The PO provides the what, the team validates the how and the feasibility. If the team cannot reach a consensus on feasibility, the item is ineligible for the current Sprint.

Authorized by: Julian Vance, Chief Architect