Agile Sprint Planner Google Sheets Template (Free)

Why Run Sprint Planning in Google Sheets

Most teams already track stories in Jira, Linear, or another issue tracker. Sprint planning is a different job. You need to size the work against actual capacity, set a realistic commitment, and walk out of the room with a sprint goal everyone agrees on. A spreadsheet is faster for that than any tool.

Google Sheets gives you four things issue trackers do not. A flat capacity calculation that includes PTO and meetings. A live point total as you drag stories in or out. A burndown that updates as you mark items Done. And a single tab you can paste into a Slack message after planning ends.

This guide walks through building a working sprint planner from scratch in about 30 minutes. If you also need a stakeholder-facing roadmap, pair this with our Google Sheets roadmap template guide and the agile roadmap in Google Sheets walkthrough. The free Sprint Planning Template packages everything below into a single copy-and-go file.

Step 1: Set Up Four Tabs

A working sprint planner uses four tabs, in this order:

• Capacity: How many points the team can commit this sprint
• Backlog: Every story the team could pull in, scored and ranked
• Sprint: The committed subset for this sprint
• Burndown: A daily completion chart that updates automatically

Keep them in this order so the natural read goes capacity then backlog then commitment then burndown. If you mix them on one tab you will lose track during planning.

Step 2: Build the Capacity Tab

Capacity is the upper bound for what the team can commit. Get this number wrong and the sprint goal is fiction before you start.

Set up these columns:

The formula in the Capacity column:

=(B2 - C2) * (1 - D2) * E2 * F2

Sum the column at the bottom for total team capacity. That number is the ceiling for everything that follows. If your team is new and you have not measured velocity yet, the Sprint Capacity Calculator walks through a more detailed estimate.

For teams running Scrum, the focus factor is usually 0.6 to 0.7. Higher than 0.8 is a sign you are overestimating. The capacity planning glossary entry covers the underlying math in more depth.

Step 3: Build the Backlog Tab

The Backlog tab is where prioritization happens before planning. It should outlive the sprint and grow over time.

Core columns:

Set up data validation (Data > Data validation) on Story Points, Theme, and Status to keep the data filterable. Story Points should follow the modified Fibonacci scale: 1, 2, 3, 5, 8, 13. If you are using a different scale, see the story points glossary entry for tradeoffs.

Score the backlog with RICE

Add columns for Reach, Impact, Confidence, and Effort, then calculate:

=((Reach * Impact * Confidence) / Effort)

Sort by RICE Score descending so the highest-value work surfaces at the top. The RICE Calculator keeps your scoring consistent across PMs, and the RICE framework guide covers the full methodology. If RICE feels heavy for your team, the MoSCoW prioritization tool and the MoSCoW framework guide give you a lighter alternative.

Filter to Ready stories before planning

Add a filter view (Data > Create a filter) that shows only stories with Status = "Ready". A story is ready when acceptance criteria are clear, dependencies are resolved, and the team agrees on the size. This is the output of backlog refinement, and it is the only column of the backlog you should pull from during planning.

Step 4: Build the Sprint Tab

The Sprint tab is the commitment. Pull stories from the Backlog tab in priority order until you hit the capacity ceiling.

Columns:

At the top of the tab, add a live capacity check:

Total Committed: =SUM(D2:D)
Capacity Ceiling: =Capacity!G10
Remaining: =G2 - G1

If Remaining goes negative during planning, you are overcommitting. Pull a story out before you commit. Teams that learn to leave 10-15% of capacity unallocated handle interruptions and bugs without blowing the sprint goal.

Color-code status

Apply conditional formatting (Format > Conditional formatting) to the Status column:

• To Do → Light gray
• In Progress → Yellow
• In Review → Light blue
• Done → Green
• Blocked → Red

This is the same pattern from our agile Google Sheets guide. Five colors, no exceptions.

Step 5: Build the Burndown Tab

The burndown chart is the live signal during the sprint. It tells you on day 4 whether you are tracking, ahead, or in trouble.

Set up two columns: Day, Remaining Points.

Day 0 equals total committed points. Each subsequent row is calculated:

=Sprint!G1 - SUMIF(Sprint!E:E, "Done", Sprint!D:D)

Or, if you want a daily snapshot, use a manual entry workflow where someone updates the Remaining Points value at the end of each day standup.

Add the ideal line

Create a third column called "Ideal" that drops linearly from total points to zero over the sprint length:

=$B$2 * (1 - A2/10)

Insert a line chart (Insert > Chart) with both Remaining and Ideal series. When the Remaining line stays above the Ideal line for 3+ days, that is a signal to cut scope at the next standup. The burndown chart glossary entry covers how to read the chart, and the burnup chart entry covers the alternative view.

Step 6: Track Velocity Across Sprints

After 3-4 sprints, you have enough data to spot a velocity trend. Add a Velocity tab with one row per sprint:

The 3-sprint rolling average is your planning velocity:

=AVERAGE(D2:D4)

Use this number as the input to your Capacity tab in future sprints. The Sprint Velocity Calculator charts this trend over time and flags outliers. The sprint velocity metric page covers what good looks like for teams of different sizes.

If velocity drops two sprints in a row, do not raise capacity in the third. Investigate first. The sprint retrospective glossary entry covers the right ceremony for that.

Sprint Planning Day Workflow

Here is the actual flow on planning day, using the spreadsheet:

1. Pre-planning (PM, 30 min): Update the Backlog tab. Score new stories. Mark Ready candidates. Filter to top 20.
2. Capacity check (5 min): Open the Capacity tab, confirm member availability, lock the total.
3. Walk the backlog (30 min): Top to bottom. For each Ready story, ask "do we commit?" If yes, paste the row into the Sprint tab. Watch the Remaining Capacity number.
4. Sprint goal (10 min): Once committed, write the sprint goal at the top of the Sprint tab. One sentence. If you cannot, your commitment is too scattered.
5. Confirm and ship (5 min): Share the Sprint tab in Slack. Owners take their stories.

Total: 80 minutes for a 2-week sprint. Half of what most teams spend.

For more on running planning effectively, see how to run effective sprint planning and the sprint planning in Google Sheets walkthrough.

When This Sheet Stops Working

A spreadsheet sprint planner works for teams up to about 10 engineers running 2-week sprints. Beyond that, you will hit three frictions:

• Manual sync between the sheet and your issue tracker eats 30 minutes per sprint
• Cross-team dependencies cannot be modeled cleanly in flat columns
• Mid-sprint scope changes do not propagate to burndown without manual recalc

If you are seeing those signals, the PM Tool Picker helps match your team's needs to a dedicated agile tool. Most teams that switch keep the spreadsheet for capacity and velocity tracking even after moving execution into Jira or Linear. It is a better surface for those numbers than any product backlog view.

Related

• Agile Roadmap in Google Sheets: Free Templates
• How to Run Sprint Planning in Google Sheets
• Agile Sprint Roadmap Templates
• How to Run Effective Sprint Planning

Sources

• Google Sheets formula reference (Google Workspace Learning Center)
• Atlassian Agile Coach: Sprint Planning
• Scrum Guide 2020 (scrumguides.org)