TechLead
Lesson 12 of 30
5 min read
Project Management

Sprint Planning and Execution

Master sprint goal setting, capacity planning, sprint backlog creation, daily standups, and burndown tracking for effective sprint delivery

Sprint Planning Overview

Sprint Planning is the ceremony that kicks off every sprint. The entire Scrum team collaborates to determine what can be delivered in the upcoming sprint and how the work will be accomplished. For a 2-week sprint, Sprint Planning is time-boxed to 4 hours.

The outcome of Sprint Planning is a Sprint Goal (a coherent objective), a Sprint Backlog (selected items + plan), and a shared commitment from the team.

Sprint Planning Two-Part Structure

  • Part 1 — What (2 hours): Product Owner presents the highest-priority backlog items. The team discusses each item, asks clarifying questions, and selects items they believe they can complete based on their velocity and capacity. Together, they craft a Sprint Goal.
  • Part 2 — How (2 hours): The development team breaks selected items into tasks (typically 4-16 hours each), identifies dependencies, and creates a plan. The PO is available for clarification but the team owns the plan.

Capacity Planning

Before committing to work, the team must calculate their actual capacity for the sprint, accounting for holidays, PTO, meetings, and other non-project work.

// Sprint Capacity Calculator
interface TeamMemberCapacity {
  name: string;
  totalDays: number;
  ptoDays: number;
  holidayDays: number;
  meetingHoursPerDay: number;
  focusFactor: number; // 0.6-0.8 (accounts for interruptions, admin)
}

function calculateSprintCapacity(
  sprintDays: number,
  members: TeamMemberCapacity[]
): {
  totalAvailableHours: number;
  perMember: { name: string; availableHours: number }[];
  recommendedPoints: number;
  capacityUtilization: number;
} {
  const perMember = members.map(m => {
    const workDays = sprintDays - m.ptoDays - m.holidayDays;
    const grossHours = workDays * 8;
    const meetingHours = workDays * m.meetingHoursPerDay;
    const availableHours = (grossHours - meetingHours) * m.focusFactor;
    return { name: m.name, availableHours: Math.round(availableHours) };
  });

  const totalAvailableHours = perMember.reduce((sum, m) => sum + m.availableHours, 0);
  const totalGrossHours = members.length * sprintDays * 8;

  return {
    totalAvailableHours,
    perMember,
    recommendedPoints: Math.round(totalAvailableHours / 6), // rough: 6 hrs per point
    capacityUtilization: Math.round((totalAvailableHours / totalGrossHours) * 100)
  };
}

// Example for a 2-week sprint (10 working days)
const sprintCapacity = calculateSprintCapacity(10, [
  { name: 'Alice', totalDays: 10, ptoDays: 0, holidayDays: 0, meetingHoursPerDay: 1.5, focusFactor: 0.75 },
  { name: 'Bob', totalDays: 10, ptoDays: 2, holidayDays: 0, meetingHoursPerDay: 1, focusFactor: 0.7 },
  { name: 'Carol', totalDays: 10, ptoDays: 0, holidayDays: 0, meetingHoursPerDay: 2, focusFactor: 0.7 },
  { name: 'Dave', totalDays: 10, ptoDays: 1, holidayDays: 0, meetingHoursPerDay: 1, focusFactor: 0.8 },
]);

// Sprint Planning Checklist
const sprintPlanningChecklist = {
  before: [
    'Product Backlog is refined — top items have clear acceptance criteria',
    'Velocity from last 3 sprints is calculated',
    'Team capacity for the sprint is determined (PTO, holidays)',
    'Dependencies from other teams are identified',
    'Technical spikes from last sprint are completed',
  ],
  during: [
    'Sprint Goal is articulated and agreed upon',
    'Team selects items based on priority AND capacity',
    'Each selected item has acceptance criteria',
    'Tasks are broken down (4-16 hours each)',
    'Dependencies within the sprint are identified',
    'Team has confidence they can deliver the commitment',
  ],
  after: [
    'Sprint Backlog is visible on the board',
    'Sprint Goal is posted where team can see it daily',
    'First day tasks are clear for each team member',
    'Any external dependencies are communicated',
  ]
};

Daily Standup (Daily Scrum)

The Daily Scrum is a 15-minute time-boxed event for the development team to synchronize and plan the next 24 hours. It is not a status report to the Scrum Master — it is a peer-to-peer coordination event.

Effective Standup Format

Each team member answers three questions:

  1. 1. What did I complete yesterday? (focus on completed items, not activities)
  2. 2. What will I work on today? (specific tasks, not vague plans)
  3. 3. What is blocking me? (impediments the team or SM need to resolve)

Anti-pattern: If standups consistently run over 15 minutes, the team is problem-solving in the standup. Problem-solving should happen after the standup in smaller groups ("parking lot" discussions).

Sprint Burndown Chart

The burndown chart tracks remaining work (story points or tasks) over the sprint duration. It shows whether the team is on track to complete all committed work by the end of the sprint.

Day Ideal Remaining Actual Remaining Status
Day 13434On Track
Day 230.632Slightly Behind
Day 327.229Behind
Day 423.823Caught Up
Day 520.418Ahead
Day 617.015Ahead
Day 713.612Ahead
Day 810.28Ahead
Day 96.83Ahead
Day 1000Complete!

Managing Scope During a Sprint

Sprint Scope Protection Rules

  • No New Work Without Removing Equivalent Work: If a critical bug must be fixed, remove a story of equal size from the sprint
  • Only the PO Can Add Items: External stakeholders go through the PO, not directly to developers
  • Urgent Items Get a Spike: If something truly urgent arises, time-box investigation before committing to fix it this sprint
  • Track Interruptions: Log every unplanned item that enters the sprint to discuss in the retrospective
  • The Sprint Goal Is Sacred: Work that does not align with the sprint goal should wait for the next sprint

Continue Learning