Capacity Planning in Agile Teams

Scrum Master Interview Question What is Capacity planning in Scrum and how to calculate? Capacity Planning in Agile is the process of determining the amount of work a team can handle during a sprint or iteration. In Agile methodologies, particularly Scrum, it helps teams plan and forecast their work while ensuring that they don’t overcommit or under-deliver. Agile teams focus on being adaptable, so capacity planning isn't about rigid long-term projections but instead about aligning work with available resources, team skills, and any potential disruptions. Sprint duration: 15 days (3-week sprint). Available hours per day for each developer: 6.5 hours (80% of 8 hours/day). Total available hours for the sprint: 591.5 hours. Maximum available hours (if everyone was available the entire sprint): 682.5 hours. Average velocity over the last three sprints: 35 story points. Available hours for the upcoming sprint: 591.5 hours. Step 1: Understanding Team Capacity The maximum hours if resources are available for the entire 15 days is 682.5 hours. But the actual available hours in the upcoming sprint is 591.5 hours. Step 2: Adjusting Velocity Based on Available Hours The average velocity from the last three sprints was 35 story points when the team had 682.5 hours available. Now, we need to adjust this velocity based on the available hours for the upcoming sprint, which is 591.5 hours. We can use the following formula to calculate the proportional velocity for the upcoming sprint: Adjusted Velocity=(Available Hours for Upcoming Sprint / Maximum Available Hours)×Average Velocity Plugging in the values: Adjusted Velocity=(591.5 / 682.5)×35 = 30 Step 3: Conclusion Based on the available 591.5 hours, the team can realistically plan for around 30 story points in the upcoming sprint, considering their historical velocity and current capacity.

What is Capacity planning in Scrum and how to calculate? Capacity Planning in Agile is the process of determining the amount of work a team can handle during a sprint or iteration. In Agile methodologies, particularly Scrum, it helps teams plan and forecast their work while ensuring that they don’t overcommit or under-deliver. Agile teams focus on being adaptable, so capacity planning isn't about rigid long-term projections but instead about aligning work with available resources, team skills, and any potential disruptions. Sprint duration: 15 days (3-week sprint). Available hours per day for each developer: 6.5 hours (80% of 8 hours/day). Total available hours for the sprint: 591.5 hours. Maximum available hours (if everyone was available the entire sprint): 682.5 hours. Average velocity over the last three sprints: 35 story points. Available hours for the upcoming sprint: 591.5 hours. Step 1: Understanding Team Capacity The maximum hours if resources are available for the entire 15 days is 682.5 hours. But the actual available hours in the upcoming sprint is 591.5 hours. Step 2: Adjusting Velocity Based on Available Hours The average velocity from the last three sprints was 35 story points when the team had 682.5 hours available. Now, we need to adjust this velocity based on the available hours for the upcoming sprint, which is 591.5 hours. We can use the following formula to calculate the proportional velocity for the upcoming sprint: Adjusted Velocity=(Available Hours for Upcoming Sprint / Maximum Available Hours)×Average Velocity Plugging in the values: Adjusted Velocity=(591.5 / 682.5)×35 = 30 Step 3: Conclusion Based on the available 591.5 hours, the team can realistically plan for around 30 story points in the upcoming sprint, considering their historical velocity and current capacity.

🔄 Support Work in Agile & SAFe: How Much Capacity Should You Reserve? In real-world Agile implementations — especially in SAFe® environments — teams often struggle in early PIs because they forget to account for support, maintenance, and unplanned production issues. Here’s a conversation we had recently in a mentoring session: 🧩 A team failed to estimate support work during their first PI Planning. 📉 They could only achieve 50% of their PI objectives. 📌 Lesson learned? In the next PI, they reserved 30–40% capacity to handle production fixes and change requests. 🔍 Key insights: ◻️ There’s no fixed % like “Reserve 20%” in SAFe — it’s contextual, based on your system behavior and historical data. ◻️ Some teams evolve to dedicated support teams, while others adapt sprint-by-sprint. ◻️ It often takes 3–5 PIs for teams to mature their planning accuracy. 🧠 Whether you’re in SAFe or any Scrum environment, planning for support work isn't optional — it's essential. Your retrospectives and delivery patterns should guide how much capacity to reserve. 💬 How does your team plan for unplanned work? Do you reserve a fixed %? Share your approach below ⬇️ #SAFe #AgilePlanning #SprintPlanning #PIPlanning #AgileExecution #AgileDelivery #ScaledAgile #ProductDevelopment #iZenBridge

It’s January and roadmaps are being polished & priorities set. But here’s an uncomfortable truth: even experienced leaders are probably overcommitting right now. Why? Because most leaders focus on the dream (the roadmap) and don’t pay enough attention to the reality: their team’s capacity. The result over the course of a year is missed deadlines, frustrated teams, and possibly burnout. Here’s what most leaders overlook when they don’t do detailed capacity planning: ➡️  Invisible work (bugs, tech debt, support) eats up from 20-50% of bandwidth. My friend Alberto Silveira talks about this in his book. ➡️  Assuming perfect productivity when talking to product or the business. ➡️  Buffers aren’t optional—80% utilization max is your safety net. Capacity planning may not be flashy, but it’s the secret to delivering on big goals. Anchor your plans in reality: 1. Know your team’s true bandwidth. 2. Prioritize ruthlessly—say yes to what matters most. 3. Build in buffers for the inevitable surprises. Roadmaps are aspirational & engineering capacity is the constraint on them. Plan thoughtfully and you’ll turn aspirations into outcomes without burning out your team. How are you handling capacity planning this year? Let’s share strategies for making 2025 a success. 🚀 #technocratic #cto