The team only has to answer 2 questions in Sprint Planning, but they’re big ones:
- What can we do in this sprint?
- How are we going to do it?
Only the Development Team can answer those 2 questions. Nobody else can tell them how much work they can do, or how they should do it. Therefore, the Development Team leads sprint planning
First the whole team works together to create the Sprint Goal.
Then, the Development Team moves tickets one by one from the top of the prioritized Product Backlog into the Sprint Backlog. They stop when they feel like the Sprint is full enough.
After that, the Development Team self organizes around the work and creates a plan for the sprint. This is where they discuss parallel vs. sequential work, or decompose tickets that are too big, etc.
Voila! That’s a planned Sprint!
For more information, see the Scrum Guide section on Sprint Planning.
Anti-patterns:
- Sprint Planning shouldn’t be led by anyone besides the Development Team. Not the Scrum Master, not the Product Owner, not the PM. It’s harder for the Development Team to take ownership of their work if they aren’t leading the discussion.
- Sprint Planning shouldn’t gather a collection of unrelated tickets for the Sprint. As much as possible, tickets should all relate to the single Sprint Goal so that people can work together towards a single iteration.
- Sprints should never be pre-planned before Sprint Planning starts. The Sprint Backlog should be empty when Sprint Planning starts, so there’s no hidden pressure to commit to a pre-planned sprint. I’m talking to you, Product Owner who puts tickets into “sprint buckets” before Sprint Planning.
Mike Crittenden 