Google Sheets works exceptionally well for sprint planning because it's free, accessible to all team members, and requires no additional tool integration. Unlike specialized project management software, Sheets lets you customize your workflow without complex setup, and changes sync instantly across your team. For product managers managing small to medium-sized teams, this approach reduces friction while maintaining structure.
Why Google Sheets
Google Sheets eliminates barriers to adoption that often derail planning processes. Your entire team already has access through Google Workspace, which means no onboarding, no learning curve, and no subscription costs. The spreadsheet format works naturally for tracking user stories, estimating effort, and monitoring sprint capacity. Real-time collaboration ensures everyone sees the same information, and the built-in commenting system keeps discussion tied directly to work items.
Many product teams start with Sheets because it's the fastest path from "we need to plan sprints" to "we're planning sprints." You can iterate on your process structure without vendor lock-in. When your team grows or needs more sophisticated tracking, migrating your data remains straightforward. This guide shows you exactly how to build a sprint planning sheet that your team will actually use.
Step-by-Step Guide
1. Create Your Sprint Planning Template
Start by opening Google Sheets and creating a new blank spreadsheet. Name it "Sprint Planning [Year]" so you can maintain separate sheets for each year. Add a title in cell A1 that reads "Sprint Planning" and format it in bold, 14pt font. In row 3, create headers for your sprint details: put "Sprint Number" in A3, "Sprint Start Date" in B3, "Sprint End Date" in C3, and "Sprint Goal" in D3.
Fill in your sprint details in row 4. For example, if you're planning Sprint 25, enter "Sprint 25" in A4, the start date (like 1/22/2024) in B4, the end date in C4, and your sprint goal in D4. Format the date columns as dates by selecting cells B4:C4, clicking Format in the menu bar, selecting Number, then Date. This ensures dates display consistently and sort properly if you reference them in formulas.
2. Build Your User Story Table
Row 6 is where your main work tracking begins. Create column headers here that include: Story ID (A6), Title (B6), Description (C6), Story Points (D6), Assignee (E6), Status (F6), Priority (G6), and Notes (H6). These columns give you the core information needed to manage sprint work without overwhelming detail.
In column A, create unique story identifiers like "US-001", "US-002", and so on. This makes referencing stories in discussions and retrospectives much easier than using row numbers. In column D (Story Points), restrict entries to valid estimates by setting up data validation. Select the entire column D starting from D7, go to Data menu, click Validation, choose List from dropdown, and enter "1,2,3,5,8,13" as your allowed values. This enforces consistent estimation using standard Fibonacci sizing.
For the Status column (F), use data validation again to create a dropdown. Select F7 downward, go to Data > Validation, enter "Backlog,In Progress,In Review,Done" as your list. This creates consistent status tracking without typos. For Priority (G), use another dropdown with values "High,Medium,Low" to help with sprint focus.
3. Add Capacity Planning Calculations
Jump to column J to set up capacity tracking. In J3, type "Total Sprint Capacity (Hours)" and put your team's total available hours in J4. For a 2-week sprint with 5 developers working 40 hours per week, that's roughly 400 hours (accounting for 10-15% overhead for meetings). You'll adjust this based on your actual team.
In J6, create a "Hours Remaining" tracker. Use the formula =J4-SUMIF(E:E,"<>",I:I) to subtract all assigned hours (column I) from your total capacity. This automatically updates as your team logs hours against stories. In column I, next to Assignee, add header "Estimated Hours" in I6, then team members enter their time estimates for each story they're assigned to.
Below your capacity tracker, in J8, type "Utilization Rate" and in J9, enter the formula =SUMIF(I7:I200,"<>0")/J4 formatted as percentage. This shows what percentage of your sprint capacity is allocated. Aim for 80-85% utilization to leave room for unexpected work and interruptions. You can reference our tool for more detailed capacity calculations if needed.
4. Implement Filtering and Sorting
Select your entire header row (row 6) by clicking on the row number 6. Then go to Data in the menu bar and click Create a Filter. This adds filter arrows to each column header. Now your team can filter by Assignee to see their own work, filter by Status to see which stories are in progress, or filter by Priority to focus on high-value work.
Sort your backlog by Priority descending so high-priority stories appear first. Click the arrow in the Priority column (G), select Sort Z-A (which puts High first). This visual ordering helps during standup meetings when you want to discuss the most important work first. You can sort by other criteria during the sprint: by Assignee to see individual workloads, or by Status to see what's blocked.
5. Set Up Sprint Metrics Dashboard
In the top-right corner, starting around column K, create a simple metrics dashboard. In K3, type "Sprint Metrics" and format it bold. Below that, create labels for key metrics: "Stories Started" (K5), "Stories Completed" (K7), "On-Track Stories" (K9), and "At-Risk Stories" (K11).
In L5, use the formula =COUNTIF(F:F,"In Progress") to count stories that have started. In L7, use =COUNTIF(F:F,"Done") to count completed stories. For on-track stories in L9, use =COUNTIF(F:F,"In Progress")+COUNTIF(F:F,"Done"). For at-risk work in L11, use =COUNTIF(E:E,"<>")+COUNTIF(F:F,"In Review")-COUNTIF(F:F,"Done") to identify stories that are assigned but not yet done.
These metrics give you at-a-glance visibility into sprint health. During daily standups, you can reference these numbers to identify patterns: are stories getting stuck in "In Review"? Are too many stories in progress at once? This data helps drive your team's process improvements.
6. Create a Burndown Chart
In the same metrics area, you'll track remaining work. Create column headers for your burndown: in K14 type "Day", L14 "Ideal Hours Remaining", and M14 "Actual Hours Remaining". For a 10-day sprint, list days 0-10 in column K (K15 through K25).
In L15, enter your starting capacity (=J4). In L16, create a formula that subtracts daily effort: =L15-(J4/10). This creates the ideal burndown line. Copy this formula down through the sprint days. For actual remaining hours in M15, start with your capacity, then each day team members update the Estimated Hours column (I) and the formula automatically recalculates.
Highlight both columns L and M, then go to Insert > Chart. Google Sheets will create a line chart showing your ideal burndown versus actual progress. This visual makes it immediately obvious if you're on pace or if you need to descope work. Print or share this chart during daily standups to keep the team aligned on pace.
7. Add Story Acceptance Criteria
In columns beyond your main tracking (starting around column N), create space for acceptance criteria. In N6, type "Acceptance Criteria". In each story row, describe what "done" means for that story. For example: "User can filter by date range without page reload" and "Filter persists when user navigates back to page."
Use bullet points within each cell by pressing Ctrl+Enter (or Cmd+Enter on Mac) to add line breaks within a cell. This keeps your acceptance criteria organized without creating separate rows. When you reach the "In Review" status, team members can reference these criteria to verify the story truly meets requirements. This prevents the common problem of stories bouncing back and forth between in-review and in-progress.
8. Set Up Recurring Sprint Updates
Create a simple log below your main table (around row 35) for daily updates. Type "Daily Sprint Updates" and create columns for Date, Blockers, Completed Items, and Coming Tomorrow. Each day, someone (rotating responsibility works well) updates this section during standup.
This creates a written record of what happened each day, separate from your status changes in the main table. When you do sprint retrospectives, you can reference this history to discuss what went wrong and what went well. It's also helpful when new team members join mid-sprint and need to catch up on context.
Pro Tips
- Use conditional formatting on Status column: Select column F, go to Format > Conditional Formatting, and color-code statuses (Done = green, In Progress = blue, Blocked = red). This makes sprint health obvious at a glance without reading every cell.
- Create a separate "Backlog" sheet: Keep your current sprint on one sheet and your full backlog on another within the same spreadsheet. Reference the backlog sheet when you need to pull in additional stories mid-sprint.
- Protect headers from accidental changes: Select row 6, go to Data > Protect Sheets and Ranges, and protect that row from editing except by you. This prevents team members from accidentally moving columns around.
- Link to your guide for context: Add a note at the top of your sheet with links to your team's agile process documentation so new team members understand your workflow.
- Track cycle time: Add a "Date Started" (column J) and "Date Completed" (column K) to calculate how many days each story takes from start to finish. This data helps with estimation accuracy over time.
When to Upgrade to a Dedicated Tool
As your team scales, Google Sheets limitations become obvious. If you're managing more than 100 concurrent stories across multiple teams, or if you need automated workflows like story-to-deployment tracking, it's time to look at dedicated tools. When you need burndown charts that auto-update from time tracking systems, or when you want to integrate with GitHub for commit-level visibility, Sheets becomes a bottleneck.
Consider upgrading when your team spans multiple time zones and you need real-time notifications about blockers, or when you're running multiple sprints in parallel and need portfolio-level visibility. If your PM is spending more time managing the sheet than doing strategic work, that's another signal. Check out our PM tools directory for options, or read our comparison to understand alternatives.