Effective Scrum Planning Techniques

Real Sprint Planning: How Scrum Masters Actually Calculate Capacity, Velocity & Estimation — The Kiran Way People often talk theory… but let’s look at a real scenario Scrum Masters handle every sprint. Here’s a practical example from a 2-week sprint (10 working days) with 10 team members 👇 🧠 1️⃣ Step 1: Calculate Real Capacity (Hours) Total possible hours 10 members × 8 hrs × 10 days = 800 hrs Subtract leaves • Member A → 2 days off = 16 hrs • Member B → 3 days off = 24 hrs Leaves total = 40 hrs Subtract buffers • Tech Debt = 10% of remaining hours • Meetings / Support = 10% (760 × 20% = 152 hrs) 🔹 Real usable capacity 800 – 40 – 152 = 608 hrs This is the actual energy your team has for the sprint. 📈 2️⃣ Step 2: Connect Capacity With Velocity Last 3 sprints delivered: • 38 SP • 42 SP • 40 SP Average Velocity = 40 Story Points With ~600 hrs usable, this matches perfectly with your expected 40 SP commitment. 🧩 3️⃣ Step 3: Add Work Based on Estimation Now: • Bring refined backlog • Select stories supporting the Sprint Goal • Stop when you reach ~40 SP or ~608 hrs This is how you avoid overloading the sprint. 🔥 Kiran Way Summary ✔ Capacity = actual hours available ✔ Velocity = actual delivery capability ✔ Estimation = actual effort required When you match these three, sprint planning becomes predictable, calm, and value-focused — not a guessing game. 👉 How does your team calculate Sprint Capacity — hours, points, or both? #Agile #Scrum #ScrumMaster #SprintPlanning #Velocity #CapacityPlanning #AgileCoach #ProjectManagement #DeliveryExcellence #Estimation #AgileMindset #ContinuousImprovement

Rethinking Story Pointing in Agile SCRUM I've worked with many software development teams using Agile SCRUM, and I’ve often seen the time and energy spent on story pointing spiral out of control. Estimating whether a story is a 1, 3, 5, 8, or 13-point effort can lead to endless debates, I think it's a waste of time. Instead, I've found that simplifying the process makes a huge difference. Here’s what I know works better: Set each story to 1 story point. The goal is to ensure that each story can be completed within a single day. If it’s going to take longer than that, break it down into smaller, 1-point stories. This way, we eliminate the wasted time spent on figuring out point values and avoid subjective estimations. It also makes calculating team velocity straightforward since each story is consistently valued. This method has great benefits: - Focused Delivery: Breaking stories down encourages the team to think in bite-sized, deliverable pieces. Which results in faster code reviews, faster testing, and increases productivity. - Streamlined Planning: Less time debating sizes, more time building, and shorter meetings. - Consistent Velocity Tracking: Easier to measure progress and providing more concrete estimates to stakeholders. For over 10 years, I’ve successfully used this method with teams I’ve led across multiple companies, proving its effectiveness for small, medium, and large-scale projects. What are your thoughts? Have you tried similar approaches?

Release Notes Updated Chapter: “Beyond Kaizen to Kaikaku: Two Patterns That Transform Good Scrum to Great” https://lnkd.in/eASMHWPg Overview The latest update to First Principles in Scrum: Implementing Scrum and Agile Practices introduces a transformative chapter focusing on two core patterns, the “Happiness Pattern” and “Scrumming the Scrum.” These patterns enable teams to elevate their Scrum practices from incremental improvements (Kaizen) to radical transformation (Kaikaku), driving significant productivity and morale enhancements. Key Enhancements 1. Happiness Pattern Introduction: • Purpose: Establishes a precise tool for identifying high-impact impediments through happiness metrics. • Method: Prompts team members to rate their happiness on role and organizational level, with a focus on identifying actionable changes for the upcoming sprint. • Outcome: Empowers teams to convert broad dissatisfaction into specific improvements, driving iterative yet impactful changes. 2. Scrumming the Scrum: • Description: A systematic approach to remove the most significant impediments identified through the Happiness Pattern. • Implementation: Ensures that high-priority impediments are tackled at the start of each sprint, creating a streamlined focus on improvement before other sprint tasks. • Impact: The combination of these two patterns results in a rapid, compounding performance improvement through continuous focus and feedback loops. 3. Case Studies on Rapid Transformation: • Scrum Inc.: Highlights how one-week sprint cycles, happiness tracking, and empowerment led to a 500% performance boost and rapid resolution of major impediments. • Microsoft: Demonstrates adaptation to Scrum in a large organizational setup using temporary solutions for immediate action. • Toyota: Details the shift from large team sizes to smaller, empowered Scrum teams, achieving a full project turnaround in six months. 4. Key Takeaways for Agile Leaders: • Pattern Precision: Emphasizes the importance of exact pattern implementation, advocating for one-week sprints and iterative action on impediments. • Kaikaku Mindset: Encourages leaders to foster a culture of continual transformation, aiming for revolutionary changes that drive productivity and team satisfaction. • Transformative Leadership: Urges leaders to inspire teams by sharing a vision for improvement, supporting self-organization, and embracing bold actions. 5. Common Pitfalls & Solutions: • Addresses common errors such as defaulting to two-week sprints, treating happiness as a lagging metric, and implementing multiple improvement stories per sprint. • Provides guidance on focusing on one high-leverage improvement per sprint and reinforcing the synergy between Happiness and Scrumming the Scrum patterns.

An easy step to improve a team’s estimates is triangulating. The name refers to how sailors could determine a ship’s position using landmarks on the horizon before the GPS devices became available. A ship’s navigator would look at two known landmarks and draw a line to each on a map. The intersection of the lines would be the ship’s location. How do you use this to get better estimates? Compare the item you’re estimating to two other items you’ve already estimated. For example, if a team is considering estimating something as five points, compare it to an eight and a three. If the item seems a bit smaller than an eight and a bit larger than a three, then five is probably a good estimate. You want to compare against ➡ one item that is the same size or slightly bigger ➡ one item that is the same or slightly smaller Comparing against more than two items usually isn’t worth the extra effort. Choosing good items to compare against is critical. You want to select items that were themselves estimated well. To do this, at the end of each sprint, have the Scrum Master or team members collectively note any finished items that will be good to use in future comparisons. Look for items ✅That seem like they had the right estimate after they’ve been developed ✅Team members agree on. Don’t compare against an item that half the team thinks should have been five and the other half thinks should have been eight. I coach Scrum Masters to maintain a list of these exemplary comparison items. It doesn’t need to be a long list—no more than three items of each value is plenty. Then when a team is estimating, the Scrum Master can look at this list and suggest good comparisons. Age out older items. A team will be much better able to triangulate against an item they worked on three months ago than an item they worked on when gladiators fought in the Roman Coliseum. A benefit of triangulating is that it can speed up your estimating sessions. When team members start to bog down in an argument over the best value, triangulate it. This may not immediately settle the dispute but it generally will move a team closer to consensus.

🔄 Scrum Events Driving Devs Crazy? Fix the Format, Not the Framework Here’s How Scrum Masters Can Make Them Timesaving Instead of Just More Popular Let’s be honest: 🙄 Daily stand-ups feel like roll calls. 📊 Sprint Reviews turn into slide shows. 🔁 Retrospectives become group therapy or worse… silence. Sound familiar? Developers are quietly (or loudly) frustrated—and not because they hate collaboration, but because they value time. And when Scrum events start to feel like pointless rituals, we’ve got a problem. As Scrum Masters, our job isn’t to force fun or sell Scrum with emojis and snacks. It’s to make every minute count. 💯 So how do we fix the fatigue and flip the narrative? Here are 5 brutally effective strategies to make Scrum events efficient, energizing, and engineer-approved: ✅ 1. Timebox Like a Boss (And Stick to It) Don’t just set the timer—enforce it. If a 15-min stand-up turns into a 40-min status circus, you’ve already lost your audience. 🔆 Hack: Use a visible countdown timer. Appoint a “Time Cop.” Reward brevity. ✅ 2. Ditch the Template Talk Same old “Yesterday, Today, Blockers”? Developers check out by the third update. 🔆 Instead: Ask “What’s the riskiest thing you're working on today?” Or “What could derail the sprint if not addressed?” Make it real. Make it relevant. ✅ 3. Retrospectives Need Redesign, Not Routine Tired formats kill creativity. Instead of the usual “What went well / didn’t,” try: 🔆 “One thing we should never do again?” 🔄 “What slowed us down that we can automate?” ⁉️ “What’s one experiment we’ll run next sprint?” ✅ 4. Sprint Planning ≠ Torture Planning shouldn’t drain energy—it should focus it. Break it into smaller, focused chunks: 🧩 Vision & Goals 🧩 Capacity Reality Check 🧩 Item-by-Item Planning (with dev input prioritized) Bonus tip? Come prepared with well-groomed backlog items or cancel it altogether. Nothing drains morale like planning chaos. ✅ 5. Stop the Slide-Show Sprint Review Reviews should demo working software, not working on PowerPoint. 👀 Let devs show the code in action. 👂 Let stakeholders give real feedback (not just applause). 📌 Capture next-step decisions live. 💬 Final Thought Scrum isn't broken. But the way we do Scrum often is. Scrum events aren’t sacred ceremonies—they're high-leverage checkpoints. If they’re annoying your team, don’t defend the ritual. Redesign the experience. Because the goal isn't just “popular” Scrum. It’s practical, purposeful, powerful Scrum. ✋ Your devs will thank you. 📈 Your outcomes will prove it. 🔔 And if you're a Scrum Master looking to level up beyond the basics, follow me—we’re just getting started. ♻️ Repost to help your network hashtag #AgileCoach #ScrumMaster #CareerGrowth #AgileLeadership #AgileTransformation #AgileMindset #CoachingJourney #ServantLeadership #LinkedInLearning

Scrum: What to Do When You Run Out of Time Before You Run Out of Work Or Run Out of Work Before You Run Out of Time Scrum teams often face two uncomfortable situations: 1) Sprint ends with unfinished work 2) Sprint isn’t over, but all planned work is done (for one, some, or all developers) Both scenarios indicate a mismatch between planning and execution, so let’s talk about what to do about it. More Work Than Time This is the more common issue. Incomplete work spills into the next sprint, frustrating teams and stakeholders and disrupting forecasts and roadmaps. Possible Causes Overcommitting: Pulling too much work given capacity. Underestimating: Stories were more complex than expected. Unplanned Work: Interruptions, defects, or urgent requests disrupted the sprint. Wait-States: Dependencies, external approvals, or bottlenecks caused delays. What To Do Analyze Root Causes: Identify underlying problems during Retro. Adjust Sprint Planning: Use past performance, not optimism. Improve Refinement: Write smaller stories with clear acceptance criteria (use INVEST or FOCUS methods). Minimize Interruptions: Shield the sprint from ad-hoc work and revisit prioritization. Collaborate Effectively: If some developers finish early, swarm to meet the sprint goal. More Time Than Work Less common, but it happens. Just because some (or all) team members finish early doesn’t mean the sprint is over. Possible Causes Unbalanced Work Distribution: Some developers finish faster than others. Undercommitting: The team consistently finishes early but doesn’t increase its commitment. Inflexibility: The backlog isn’t ready with enough well-refined stories. Faster-than-Expected Dependencies: Rare, but possible. What to Do Swarm: Scrum is a team sport. If some devs finish early, they should help the rest of the team complete the sprint goal. Pair programming, testing, reviewing pull requests - anything that helps the team. Improve: Pay down tech debt. Refactor, improve test coverage, optimize CI/CD pipelines. Automate tedious manual tasks. Improve documentation. Streamline workflows. Up-skill: Learn a new tool, improve domain knowledge, or cross-train. After you've exhausted the options above... Pull New Work: Only pull in work the team is collectively confident can be completed. This may require skipping top priorities to find something small enough. Help Another Team: If another team is struggling with dependencies, collaboration can make sense. Just be sure your "help" doesn't create fragmentation or disrupt focus. Scrum Is About Execution And Adaptation Neither of these scenarios is a failure. The only failure is failing to adapt if they keep happening. Sprint-to-sprint fluctuations are normal, but if patterns form, refine the way the team works. Scrum teams succeed together. If work is unfinished, help finish it. If work is done, improve the team. The best teams don’t just track these issues; they learn, adapt, and improve every sprint.

Backlog Refinement = Turning ideas into small, clear, and sprint-ready user stories. It’s a collaborative exercise with PO, Developers, QA, and the Scrum Master. When a story is estimated at more than 8 points, it’s a strong signal: The scope is too big The risk is high The story isn’t ready for the sprint To break it down effectively, use the Spider Slicing Technique, which helps split the story across five angles: Workflow steps UX / UI Validations Data rules Edge cases This approach turns a large, unclear story into multiple 3–5 point items that are testable, predictable, and easier for the team to deliver. If you want to see the full breakdown, I’ve attached a slide presentation for a clearer visual explanation. Small stories = smoother sprints. Clear refinement = predictable delivery. #Agile #Scrum #BacklogRefinement #StorySlicing #ProductManagement #ProjectManagement #SoftwareDevelopment #TeamCollaboration #TechLeadership #SoftwareEngineering #AgileDevelopment #ScrumMaster #Productivity #WorkSmart #LeanAgile

"All the Scrum events are planning events" I had some comments on my last post from Michael, David and Edgardo About the "Sprint Planning can be long and tiring" We have all lived long and tiring events Thank you all for your comments You rock! Let me share one way you can reduce Sprint Planning First Let's go back in time Sprint Planning used to have 2 "topics" The What and the How 1. What can be done in this Sprint 2. How will the chosen work get done Some teams may feel that the Product Owner should bring the Sprint Goal Quite understandable, as it was implicitly described in the "What" "The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal" Fast forward back to the present Now Sprint Planning has 3 "topics" The Why, the What, and the How 1. Why is this Sprint valuable 2. What can be done in this Sprint 3. How will the chosen work get done The Sprint Goal is now defined in the "Why" topic "... The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders" The Product Owner brings 3 things 1. The Product Goal 2. Why will the Sprint be valuable to Stakeholders 3. An ordered Product Backlog that supports the Why I have an approach that I designed You may have already done this before It is based on one principle that is not mentioned in Scrum "All the Scrum events are Planning events" Which means you can progressively add items to a Sprint You don't have to fill up the Sprint Backlog I called it Progressive Sprint Planning You progressively add Product Backlog items with full transparency Instead of adding "Transparency" progressively to a Sprint Backlog You Iterate through the "Why" the "What" and the "How" For each Product Backlog Item When you have enough to start the sprint, that is: 1. The Sprint Goal is defined 2. Product Backlog items are transparent on the Why, What and How 3. The initial plan is set, everyone knows what they are doing next and they have enough to last a few days with inspection and adaptation You start the Sprint with room for new work You can pull in new work whenever, just like Kanban signals The Daily Scrum ensures: 1. The next 24 hours is known 2. And enough work rolling for a few days Some would say this is Scrum+Kanban I would say "not yet" As there are other principles But this "way" for me, is what Scrum should be - Empirical - Teams being adaptable - And killing the fixed mindset of rigid Scrum "All the Scrum events are Planning events" Thoughts, questions, challenges, ideas, ahah moments, whatever... I'll see you in the comments! #marcob ----------------- Follow me for more Better Scrum 🔔 Cohorts are starting 29th June, 2nd July and 4th July Progressive Sprint Planning is available in the "Better Scrum Starter Kit"

Teams hit roadblocks in 70% of sprint plannings. One wrong move derails everything. What if scattered focus or hidden risks are killing your velocity right now? → 7 𝐏𝐢𝐭𝐟𝐚𝐥𝐥𝐬 (𝐚𝐧𝐝 𝐅𝐢𝐱𝐞𝐬) 𝐄𝐱𝐩𝐨𝐬𝐞𝐝 • Unclear Sprint Goal Problem: Scattered work, no alignment. Avoid: Define collaboratively before planning. • Over/Undercommitting Problem: Missed targets or wasted capacity. Avoid: Base on historical velocity and real capacity. • Unrefined Backlog Items Problem: Ambiguity slows development. Avoid: Groom with clear acceptance criteria. • Missing Key Participants Problem: Weak commitment, misalignment. Avoid: Full Scrum team present, PO engaged. • Ignoring Capacity/Absences Problem: Overcommitment, unfinished work. Avoid: Adjust for vacations upfront. • Work Not Broken Down Problem: Hard to estimate/track. Avoid: Split into small, testable tasks. • Skipping Risks/Dependencies Problem: Sudden blockers. Avoid: Discuss and resolve in planning. Master these. Velocity soars. Teams deliver. Follow Carlos Shoji for more insights

🚨 A Hard Truth: Planning Sprints to 100% Capacity is Planning for Failure If you treat Sprint Planning like packing a suitcase to the brim, do not be surprised when it bursts. Why it fails: ❌ Complex work always brings surprises you did not plan for ❌ Teams need room for learning, collaboration, and solving problems ❌ If you do not save capacity for improvements, Retrospectives become empty talk ❌ When there is no slack, teams hide unfinished work instead of being transparent ❌ A Sprint Backlog is a forecast, not a contract. Treating it like a guarantee kills trust Scrum is not about keeping people 100% busy. It is about creating a Done Increment and delivering on a Sprint Goal that moves you closer to your Product Goal. The Sprint Goal is the anchor. Without it, a packed Sprint Backlog just becomes a random pile of tasks. ✅ Healthy Sprint Planning leaves space for emergent work ✅ Saves capacity for continuous improvement ✅ Focuses on outcomes, not busyness ✅ Forecasts what is valuable, not filling every hour 👉 The right question is not "How do we maximize utilization?" 👉 It is "What is the most valuable work we can reliably deliver this Sprint to achieve our Sprint Goal?" Because utilization looks good in a plan. But Done, and improving how you work, is what actually matters. 🔥 Busy teams do not build great products. Focused teams do.