Sprint Planning
At Meera's first sprint planning as manager, the team pulls in twenty tickets, the same as always. Nobody mentions that Kabir is on leave for four days, that Arjun is on call, or that the sprint should end with something customers can use. Two weeks later, half the tickets are unfinished and nothing has shipped.
The rule
Plan for the team you'll actually have, around one clear goal.
Most software teams work in an agile way: short cycles, often one or two weeks, with something usable at the end of each and a look back to adjust before the next. Scrum is a popular version built on fixed-length sprints. Kanban drops sprints and instead limits how much work is in progress at once. Whatever the flavour, planning comes down to three things.
- Capacity. Count the working days the team actually has. Take off leave, holidays and on-call duty, then leave room for meetings, code reviews and surprises.
- A sprint goal. One sentence that says why this sprint matters: "Customers can save a card and pay with it on Android." A list of ticket numbers is not a goal, because it can't help you decide what to drop when things go wrong.
- Pulled work. Take the highest-priority items that serve the goal, until the estimates fit the capacity with some slack left over.
The team estimates and commits, not the manager. Meera's job is to run a good conversation: bring the capacity numbers, make the trade-offs visible, and protect the plan from work that tries to sneak in halfway through.
The shortcut
Work in this order: capacity first, goal second, tickets last. If you start from the tickets, you plan for a team you don't have.
Count capacity
Five engineers × 10 days = 50 days. Kabir is on leave for 4, leaving 46. Arjun is on call and counts as half, leaving 41. Meetings and reviews take about a fifth, so the team has roughly 33 days of focused work.
The common mistake is planning to 100 per cent of capacity. Unplanned work always arrives, so a completely full plan is a plan to miss.
Drills
Answer fast — trust the rule.
Which of these is a sprint goal rather than a to-do list?
A team of four engineers has a ten-day sprint, and one of them is on leave for five days. How many engineer-days does the team have before meetings are taken off?
Who should estimate and commit to the sprint's work?
Why leave slack instead of planning to full capacity?
Remember
- Plan for the team you'll actually have, around one clear goal.
- Capacity first, goal second, tickets last.
- Never plan to 100 per cent; leave slack for the work nobody scheduled.