Welcome to the Scrum Masters Skills Series! In part 1, I share my notes on how to facilitate a great Sprint Planning session. Enjoy!
- Create an experience. Design the experience. Want the team to feel positive? Design a positive experience.
- Set a recurring appointment series--the same time and place every sprint-start. Not a day earlier, not a day later.
- Take the full 4 hours (for a 2 week sprint).
- Get it done in one day.
- Don’t like 4 hours? Do a shorter sprint! It really does take 4 hours to plan 2 weeks of work. Don’t skimp!
- Do it as the very first event of your sprint.
- Sprint Planning goal: produce a credible plan for how to implement the next most important PBIs in the Product Backlog
Part 1: What
- All Scrum Team members are present, including the Product Owner. Ask the PO for help to clarify the intent of Product Backlog Items.
- Given: A Ready Product Backlog. If you don't have a Product Backlog in a Ready state, you're in trouble!
- Pull the highest-order items off the Product Backlog.
- Try: Do it on a wall, with Post-Its. Your Scrum kanban board can have these columns: Product Backlog, Sprint To Do, Sprint Doing, and Sprint Done.
- Try: Use your last-10-sprints average velocity (and best-3-max and best-3-min) in story points to guide you as you forecast What might fit into your Sprint.
- Development Team and Scrum Master are present. PO is available to answer subsequent questions about PBIs.
- Self organization: Dev Team plans HOW to get the PBIs done.
- Try: Decompose each PBI, one at a time, into tasks.
- Try: Each task can get done in 1 day. Helps team gauge progress every day during the Daily Scrum.
- Try: Use the PBI’s acceptance criteria to guide your task breakdown.
- Try: Use your Definition of Done, let it guide your task breakdown.
- Try: How will you demonstrate that you got the PBI done? Make sure you have tasks for the elements of the demo.
- Try: Focus on the value you’ll deliver to your stakeholders. E.g., if you don’t need documentation, don’t do documentation!
- Try: Think about risks and dependencies
- Try: Think of it as a mini-project plan, for a 2-week-long project. What are the elements of a “credible plan” for your mini-project? Did you include them all?
- Try: Estimate tasks in person-hours. Try: use last sprint’s capacity as forecast for this sprint. Try Use person-by-person availability to forecast this sprint’s capacity in person-hours.
- Try: Don’t estimate tasks in person-hours; try every task is 1 day long
- Simply state your sprint goal. Write it down. Post it on the wall with your kanban board and burndown chart.
- Try: Look each other in the eye. Put your hands in. Really agree with each other that you can do it.
- Try: Decider Protocol, Passionometer
- Draw a burndown chart, put it on the wall.
- Set up a simple kanban board for sprint planning. Play a quick sprint planning game.
- Draw a burndown chart for your sprint plan.