sprint planning & backlog management

Sprint planning is the ceremony most teams get wrong. Not because the framework is complicated — Scrum has been around for thirty years, the mechanics are well-documented. Teams get it wrong because the PM walks in unprepared, the backlog is a graveyard of stale tickets, and the session devolves into a negotiation where everyone leaves unhappy.

I have sat through hundreds of sprint planning sessions. At Pragmatic Leaders, I hear the same complaints from every cohort: “Planning takes three hours and nothing useful comes out of it.” “Our backlog has 400 items and nobody knows which ones matter.” “We committed to 40 story points and delivered 22 — again.”

These are not process problems. They are preparation problems. The sprint planning meeting is where failures become visible, but the actual failures happened in the days before it.

The PM’s job before sprint planning

Your job is not to show up on Thursday and read tickets aloud. Your job is to make sure that when the team walks into that room, the top 15-20 items in the backlog are ready to be picked up. “Ready” means three things:

The story is specific enough to estimate. If an engineer reads the ticket and their first question is “what does this mean?” — the story is not ready. Every story entering sprint planning should have clear acceptance criteria, linked designs if applicable, and explicit scope boundaries.

The story is prioritized against everything else. The team should not be debating priority in the planning meeting. That debate should have happened between you and your stakeholders before the meeting. The backlog order is your call. Own it.

Dependencies are identified and unblocked. If story A requires an API from another team that has not been built, story A does not go into the sprint. Obvious? Yes. And yet I see PMs put blocked stories into sprints every single week, then act surprised when velocity drops.

The best PMs I have worked with spend one to two hours before every sprint planning doing what I call “backlog grooming” — though many teams now call it “refinement.” The name does not matter. The practice does. You go through the top of the backlog, confirm every story is ready, reorder based on what you learned that week, and kill anything that has been sitting untouched for three months.

How to run the actual planning session

Keep it under 60 minutes. If your sprint planning regularly exceeds an hour for a two-week sprint, you are either discussing too many items or the items are not ready.

Here is the structure that works:

First 5 minutes: Sprint goal. State the one thing this sprint must accomplish. Not a list of tickets — a goal. “By the end of this sprint, sellers can initiate same-day payouts via UPI.” Everything else in the sprint supports this goal or is maintenance work that cannot wait.

Next 10 minutes: Review last sprint. What did we commit to? What shipped? What spilled over? Why? This is not a blame session. It is a calibration exercise. If you committed to 40 points and delivered 25, your capacity this sprint is 25, not 40. Stop lying to yourselves.

Next 30 minutes: Commit to this sprint. Walk through the prioritized backlog, top to bottom. For each story: PM explains the what and why (30 seconds). Engineer asks clarifying questions (2-3 minutes). Team estimates (story points or T-shirt sizes — pick one and stick with it). Commit or defer.

Last 10 minutes: Capacity check and risks. Who is on leave? Any holidays? Any known risks — API dependencies, pending design reviews, infrastructure work? Adjust commitments accordingly.

The PM’s role during this meeting is not to talk the most. It is to make sure every committed story has a clear owner, a clear definition of done, and no unresolved questions. If a story sparks a five-minute debate about implementation approach, take it offline. The planning meeting is for commitment, not design.

Backlog management that actually works

A backlog with 400 items is not a backlog. It is a landfill. Nobody scrolls past item 30. Nobody. Everything below that line is noise that makes the useful items harder to find.

The rule I enforce: if a backlog item has not been touched in 90 days, archive it. Not delete — archive. If it was important, it will come back. If it does not come back, it was never important. I have seen PMs hoard hundreds of tickets “just in case” and then complain that they cannot find anything. Your backlog is a tool, not a historical record.

Organize the backlog into three zones:

Now (top 15-20 items). These are groomed, estimated, and ready for the next sprint. Every story has acceptance criteria. Every story has a clear owner or can be picked up by anyone on the team.

Next (items 20-50). These are roughly prioritized and need refinement before they enter “Now.” They have a title and a one-line description. They do not yet have detailed acceptance criteria or estimates.

Later (items 50+). Ideas, requests from stakeholders, tech debt items that are not urgent. Review this zone monthly. Archive aggressively.

Story points and the velocity trap

Story points are useful when teams treat them as a planning tool. They become harmful when management treats them as a performance metric.

Here is what story points are for: helping the team estimate how much work they can commit to in a sprint based on historical capacity. Last three sprints you delivered 28, 32, and 26 points. Your average velocity is 29. You should commit to about 29 points this sprint. That is it. That is the entire purpose.

Here is what story points are not for: comparing teams, evaluating individual performance, or reporting to leadership. The moment you put “velocity” on a dashboard that a VP reviews, engineers start gaming the system. An 8-point story becomes a 13. Velocity goes up. Actual output stays the same. Everyone pretends this is fine.

My rule: velocity is visible to the team and the PM. Nobody else. If leadership wants to know whether the team is performing, show them shipped features and customer outcomes. Not a number that can be inflated by changing how you count.

In India specifically, I see a pattern where velocity becomes a proxy for team utilization in service companies and outsourced teams. “Your velocity dropped this sprint — are people not working hard enough?” This question reveals a fundamental misunderstanding. Velocity drops because of unclear requirements, blocked dependencies, unexpected production issues, or scope changes mid-sprint. It almost never drops because people are not working hard enough. If your instinct when velocity drops is to question effort instead of questioning preparation, you will never fix the real problem.

Handling mid-sprint changes

The purist Scrum answer is: nothing changes mid-sprint. The sprint commitment is sacred.

The real-world answer is: things change. A production outage pulls two engineers off feature work. A key stakeholder escalates a request that genuinely cannot wait two weeks. A critical bug surfaces that makes the current sprint goal irrelevant.

Here is how to handle it without destroying trust:

If the change is small (under 20% of sprint capacity): Swap it in, swap something of equal size out. Communicate the swap to the team and the stakeholder whose item got deferred. Document the reason.

If the change is large (over 20% of sprint capacity): Call an explicit mid-sprint replanning. Do not quietly adjust the backlog and hope nobody notices. Tell the team: “We are pulling in this urgent item. It costs us X points. Here is what we are dropping. Everyone agree?” Get explicit consent.

If the change is constant: You do not have a sprint problem. You have a stakeholder management problem. If every sprint gets blown up by urgent requests, the issue is that your team is being used as an on-call service, not a product team. That is a conversation to have with leadership, not something to solve with better planning mechanics.

Common sprint anti-patterns in Indian teams

I want to call out three patterns I see consistently in Indian product teams, because they are rarely discussed in Western-origin Scrum literature.

The “PM as project manager” trap. In many Indian companies, especially those transitioning from services to product, the PM is expected to track every ticket, follow up on every blocker, and provide daily status updates to leadership. This leaves zero time for actual product work — customer research, strategy, prioritization. If your sprint planning includes the PM assigning specific tasks to specific engineers, you have a project manager, not a product manager. Engineers and the engineering lead should own task assignment. You own priority and scope.

The festival sprint. India has more holidays than any country I have worked in. Diwali, Holi, Eid, regional festivals, long weekends — they cluster unpredictably and can take out 30-40% of your sprint capacity. Smart teams plan for this. Maintain a shared holiday calendar, account for it in capacity planning, and do not commit to a full sprint when half the team will be out for Dussehra week. I have seen teams commit to 40 points knowing that four out of seven engineers will be on leave. This is not optimism. It is negligence.

The “carry forward” culture. Items that spill over from one sprint to the next become permanent residents. Nobody questions why they keep spilling. Nobody asks if they should be deprioritized or broken into smaller pieces. After three sprints of carry-forward, the item is either not important enough to prioritize properly or too large to fit in a single sprint. Either way, it needs to be addressed — not silently carried forward again.

Test yourself

The one-line summary

Sprint planning is not a meeting — it is the output of all the preparation work you did before the meeting. Get the backlog right, protect the team’s capacity with data, and treat every commitment as a promise you intend to keep.

Related pages:

• Writing PRDs That Engineers Read — the documents that feed your sprint backlog
• Metrics & KPIs — measuring what your sprints actually deliver
• Prioritization Frameworks — how to decide what goes into the backlog in the first place