How do you run sprint planning for your team?
Good sprint planning ends with a goal the team believes in and a short list of tasks it can actually finish. Poor planning ends with a long list and an unhappy review.
Short answer
- Agree one sprint goal in a sentence before choosing any tasks.
- Look at the team’s velocity from recent sprints to see how much it really finishes.
- Break items into tasks that can be done in a day or two, each with an owner.
- Leave a buffer for bugs, meetings and absence.
- Close the sprint on the planned date and use the burndown to review it.
What to prepare
- A prioritised backlog, with the most important items at the top.
- Velocity from the last few sprints.
- Known absences and bank holidays inside the sprint dates.
- Open tasks carried over from the last sprint.
Planning, step by step
- Review the previous sprint: what was finished and what was not, and why.
- Agree the sprint goal in one sentence.
- Pull items from the top of the backlog until you reach roughly your velocity.
- Split large items into tasks of a day or two and give each an owner and a deadline.
- Check each person’s workload so nobody is overloaded.
- Start the sprint and share the goal with everyone.
Common mistakes
- Planning to 100% of capacity, leaving no room for surprises.
- Tasks without an owner, so nobody feels responsible.
- Adding new work mid-sprint without removing anything.
- Skipping the review, so velocity is never learned.
Example: a five-person web team
The team usually finishes about thirty points in a two-week sprint. Two people are away for two days, so they plan twenty-six. The goal is “customers can save their basket”. Every task gets an owner, and the burndown shows by day six that the work is on track.
How 4myprojects helps
- Sprints with start and close, a burndown chart and velocity per sprint.
- Tasks with owners and deadlines, and a workload view for each person.
- A chronological list of sprints, milestones and deadlines.
- Comments on tasks and an activity log for the review.