Pre-sprint planning meeting for Scrum Masters
A while back, I remember facilitating a sprint planning meeting that crashed and burned from the get-go. I was a new scrum master, working with a team of 9, very dedicated, and well-adjusted team members. Everyone was motivated, and excited to start the new sprint, and was in high spirits since the previous sprint went so well, and had great feedback from our stakeholders.
Five minutes into the meeting, I felt the energy in the room go from a 10 to a 4. The reason was simple; I was not well prepared for the meeting. For starters, I had not appropriately thought about what the main focus of the sprint was going to be; next, I had not selected the right stories to be a part of the sprint based on the conversations we had had just the previous day with our product owner. Most importantly, I had not consulted my team members, before the meeting about the viability of the stories I had planned, and they told me in the first 5 minutes, that 4 of the 9 stories I had planned, could not be done since they were waiting on a third party tool they needed to use.
Ten minutes into the meeting, I suggested that we cut the sprint planning meeting short, and meet the next day, so I am better prepared and don't waste anybody's time. Thankfully, everyone was ok with this (sign of a great team!), and I got to work.
Ever since that day, I take my sprint planning meetings VERY seriously and make sure I am as prepared as I can be while understanding that I may not have all of the answers, and that is ok. I make sure that I set this expectation with my team too.
Over the years, I have devised my checklist of what to prepare for before my sprint planning meetings.
The checklist is as follows:
Step 1: Product roadmap grooming
Step 2: Set a sprint goal/theme
Step 3: Come up with a proposed sprint backlog
Step 4: Send out the planned sprint backlog
Step 5: Send out meeting invite with details
Step 6: Prepare a launch to increase energy
I have this saved in my google drive so I can review it often, and make changes if required. I hope you find this list useful!
Step 1: Product roadmap grooming: About five days before the sprint planning meeting is due, I review our product roadmap for the upcoming release. This is also the time I have a conversation with my product owner and the technical lead(or any developer) on the team. What I want to get out of this exercise is a goal/theme for the upcoming sprint. The questions I hope to get answers for are:
What are the prominent features we want to tackle next?
What would add the most value to the end-user?
What is technically viable at this point?
Is there anything we need to de-prioritize right now?
Are there any major production bugs that we need to fix ASAP?
Are there any action items from the previous sprint retrospective we need to account for?
Step 2: Set a sprint goal/theme: Based on this conversation, I then define a goal for the sprint. A sprint can have 1-2 significant goals; it depends on the team, but what I want to do now is give this sprint a purpose and a vision for the team and the product owner. This ensures that:
Everyone is aware of the bigger picture we are working towards.
The work that we have planned for the sprint is realistic, keeping in mind the size of the team, complexity of work, technical challenges and unknowns, etc.
Keeps the team motivated.
I can push back on any stories or features that do not meet the sprint goal needs so that the team stays focussed.
Step 3: Come up with a proposed sprint backlog: Next, based on the above conversation, I come up with a proposed sprint backlog. 'Proposed' being the operative word here. Because this backlog might change based on the sprint planning meeting, and that is the whole point of the meeting in the first place. I usually like to have a list of stories ready in our project management tool, ready to go. I also make sure that every story I have planned, as a clearly defined narrative, and acceptance criteria.
Step 4: Send out the planned sprint backlog: The reason step 3 is so important is because I want to send the planned sprint backlog to my team a day before the sprint planning meeting. I do this because I want them to be prepared, just as I am, for the meeting.
In doing this, my team can have a chance to come up with their questions, concerns, and feedback so that the meeting can run smoothly and efficiently. I cannot stress how valuable this step has been in ensuring successful sprint planning meetings.
I would recommend setting clear expectations with your team that they should go through all stories in the backlog before coming in for the meeting.
Step 5: Send out the meeting invite with details: I am sure you already have a recurring sprint planning meeting invite on your team calendar, but I would recommend adding a few things to this invite like:
Sprint goal
Link to the planned sprint backlog
Previous sprint velocity(if that is something your team does track)
Burndown chart from the previous sprint
All these give your team a good idea of what to expect in the meeting.
Step 6: Prepare a launch to increase energy: This is an optional step, but one finds, totally changes the dynamic of a room and starts things on a positive note. Here are a few launches I have tried in the past:
Have a video of a stakeholder or end-user ready, talking about how a feature from a previous sprint has made their life better or added value to the product.
Have a gratitude wall ready, and ask your team members to take 5 minutes to thank someone for using a sticky note.
Snacks! Always works!
Have a quick ice breaker exercise
I hope you have found this checklist useful. I will be creating a blog post soon on running a sprint planning meeting effectively, once you have prepared for it.