Sprint Planning is an event in Scrum where the entire Scrum team comes together to review and solve (figure out how to build) Product Backlog Items (PBIs) and then add those solved PBIs to the content of the upcoming Sprint. Sprint Planning is time-boxed at approximately 2 hours per Sprint week (i.e., 4 hours for a 2 week Sprint).
Tips For An Effective Sprint Planning Event
- Avoid bringing laptops into the event. You might need one or two in the event for a little research, but everyone doesn't need one.
- Focus everyone on understanding and solving product backlog items. Leave the phones, tablets, and anything else that might be a distraction back at your desks if necessary.
- Use velocity based planning when your team is new and/or doesn't have an established velocity. Use commitment driven planning when your team does have an established velocity.
- Don't bring your backlog management tools into the event either. Most tools do nothing but slow down the discussion and innovation of the team. Write/draw your solutions on whiteboards and/or flipcharts and either take the paper with you or take pictures of the whiteboard as you go.
- Create a READIness definition for your PBIs so that items that aren't ready and might cause problems during the Sprint (too big, not well defined, etc.) are not planned into the Sprint. On that note, take no items into your Sprint that will take your team more than about three days to complete.
- Make sure you're ready for the Sprint Planning event as a Scrum Master and make sure your Product Owner is ready too. Nothing is worse than holding a planning event when you aren't ready to work. That's just wasting your team's time.
- Click HERE for more tips...
My Team Doesn't Want To Do Sprint Planning This Way. Now What?
First of all, realize that no one likes to make lots of changes, particularly to how they do their daily job. Your job, as a Scrum Master, is to remind your team that Agile IS different. If it feels comfortable, then you probably aren't doing anything different than you were before. Try to get your team to agree to try one thing (with an open mind!) and see if it helps.
Size matters when planning Product Backlog items! The larger the item, the more likely your team will make mistakes in the building of the product. In product development, BIGGER = RISKIER