Sprint planning is often the most challenging meeting for Scrum Teams. Even experienced teams that have been working together for long periods of time can have problems with their planning. Here’s what I’ve learned about this crucial event in my years as a Scrum Master.
Timing and time boxing
Development Teams and Product Owners are often caught in the trap of starting Sprint Planning even though the previous Sprint is still not finished. Of the many obvious disadvantages associated with this approach, I would point out that your team is simply not going to be focused. Ship your product (or don’t), finish your Sprint and only then start your next Sprint Planning.
The Scrum Guide places a four-hour time box on a planning meeting for a two-week Sprint. Teams often rush this and allocate less time or try to have one marathon meeting. Sprint Planning is the foundation of your entire Sprint. If you do it right, you are far more likely to have a successful Sprint. Make sure you take enough time and insist on short breaks for everyone to refresh.
Do we really need to talk about that?
There are many things that can go wrong and derail the Scrum Team during their discussion about user stories and other Product Backlog items.
One common problem I often encounter is separating the ‘what’ from the ‘how’. The Scrum Guide states that these are the two parts of a Sprint Planning meeting (what will be delivered & how will the selected work get done). I would suggest going even further and separating this into two meetings.
For Development Teams that need a detailed meeting on the second part (‘how will the work get done’), a good approach is to hold this meeting without the Product Owner and Scrum Master and invite them on an as-needed basis. This encourages self-organization and emphasizes the Development Team’s responsibility of creating a potentially shippable increment of a software product.
It takes a lot of exercise and personal discipline from everyone on the Scrum Team to get to a point where they can efficiently separate the ‘what’ from the ‘how’.
Oftentimes, Scrum Team members will (with the best intentions and unaware that they are doing so) derail the decision-making process. Another pillar of Scrum is the Product Owner’s independence and authority in product-related decisions. While it is important for everyone on the Scrum Team to voice his or her opinion and provide input, everyone has to remember that the Product Owner makes the final decision.
Finally, the entire team has to constantly hone the skill of prioritising. From a time-cost perspective, Sprint Planning is a very expensive meeting. It is easy to fall into the trap of discussing, for example, a fairly minor design decision for 30 minutes only to come to the conclusion that this decision can be made during the actual Sprint.
Stick to the ceremonies
New Scrum Teams will usually say that estimation (e.g. story points) is unnecessary. Some will even call it funny. Apart from the obvious benefit of getting a sense of how much work a team can do, you will also see if everyone understood a certain Product Backlog item in the same way. If one person sized a user story as an 8-point story and another team member marked it as a 3, the story should obviously be discussed more in terms of its impact on the product and the team’s Definition of Done.
Another helpful ceremony is the vote of confidence. At the end of your Sprint Planning meeting, have the whole team voice their prediction on the success of the upcoming Sprint. Just like with estimation, this should help teams see if they are on the same page and if they are really ready to end the planning meeting.
Conclusion
My favourite saying when it comes to software development teams is that a good team will be successful even with a sub-par process, and a team that is not adequately built will fail even with the best processes and tools.
The same could be said for Sprint Planning meetings, it all comes down to gathering a good group of people and constantly working to improve your day-to-day interactions.