Are you finding running planning sessions in a fully remote environment difficult?
Don’t worry, you’re definitely not the only one.
I’ve heard many PMs around me concerned about how effective their Sprint Planning is in a full remote setup.
Uncomfortable blanks, less engagement from your team, endless discussions around priorities…
Your role as a PM is to adapt to this new remote situation.
Hang on, here are a few tips I’ve been using as a Senior Product Manager at DAZN and TravelPerk to improve the efficiency of my own Sprint Planning in a fully remote environment.
A new reality that many of us have to get used to.
What are the main components of efficient Sprint Planning?
Let's imagine the fairly traditional 2-weeks Sprint situation with all the traditional scrum reunions such as Dailies, Refinement, Demo.
The role of the Planning meeting is to set the expectations and invite the entire agile team to choose what to work on for the next Sprint.
Typically, a PM will run a Sprint Planning into the two following parts:
Part 1 – Close the previous Sprint and define the Scope of the coming Sprint
Before jumping into the coming Sprint, take the time to go through the previous Sprint you're about to close.
If you have a 30 minutes long meeting, dedicate at least 5 minutes.
Go through the burn-up or burn-down charts and invite for a succinct introspective on why things happened the way they did.
Don't take too much time, though, as you can do that during a Retrospective meeting, but it's still quite important to mark the end of the previous Sprint.
This will also allow the entire team to see what's potentially going to be carried over into your next Sprint.
I usually start the coming Sprint by giving the Sprint Goals.
Sprint Goals
Giving Sprints a clear goal will provide transparency to your entire team on what you're trying to achieve for the coming Sprint!
This might sound like a given to many; however, it's fairly common to see in bigger Scrum teams that developers get lost between all the tasks during a Sprint.
That's even more true if you're running longer Sprints (2 weeks or monthly Sprints), so it's quite essential to give them clarity on the overall Sprint goal.
I suggest using the SMART Criteria to define your Sprint Goals.
Don't skip this part of the Sprint planning.
Too often, I've heard developers get lost in the middle of a Sprint due to a lack of direction.
Take your time to go through it. I'd suggest allocating at least 5 minutes to talk through the why of these goals.
Part 2 - Plan the coming Sprint
It's important for the PM to do the exercise of prioritizing the backlog before the planning in order to have a clean and prioritized backlog to look at during the Planning meeting.
I build my own custom 4 “sub-backlogs” within my JIRA (or Asana or any backlog tool you're using) to classify my tasks:
Backlog --> Ready for Refinement --> Refined --> To be picked.
This helps me have a much cleaner Backlog that everyone in the company can easily understand.
As a PM, your role is to make sure that the tasks in your backlog are already prioritized (using whatever prioritization approach suits you best - RICE, ICE...There are loads to choose from). Learn more about prioritization here.
If you've done your job correctly, then this part should be a piece of cake.
At this stage, the entire team will be involved in selecting the tasks that should be pre-prioritized by the PM and put them into the next Sprint to-dos.
Planning meetings
Planning meetings are not a self-validation exercise with you running the show! On the contrary, Planning meetings should be interactive and invite the entire team to share what they think could bring more impact!
How?
E.g., It could be done by using markers on the whiteboard. This part can become a bit more complex in a full remote situation.
At this stage, don't forget about anything that might impact your Sprint timings (e.g., holidays, company meetings, etc.), even more so in a full remote situation, things like childcare can happen.
Don’t worry if you don’t get it right!
Very few teams get this part right from the first tries. It takes time for a team to refine their voting and estimations approaches.
More than ever, I would encourage any PM in a full remote situation to run Retrospectives frequently. As a PM your role will be to adapt your Sprint Plannings based on your team feedback.
Never underestimate the power of Retros!
My tricks for running efficient remote Sprint Planning
1. Estimate during Refinement, Vote during Planning
As I mentioned above, the agile team will be involved in Voting to select which task will go into the next Sprint.
The footnote here is that everyone in the team has knowledge about the tasks in the backlog, even if minimal.
The best way to do this is ideally to have the entire team participate and estimate the tasks during refinement.
Timewise, I’d suggest having the Refinement 1 day (or 2 maximum) before planning. This will give you the time to handle any changes and allow everyone to remember everything the day after for planning.
Once again, it's paramount to run your refinement before your planning AND to estimate your tasks (again, based on using any methodology you prefer).
During the planning, the objective is to "vote" on what to pick next.
It's not always obvious - You might decide to pick quick wins or bigger tasks.
Don't be afraid of the discussions, and encourage engineers to ask questions. You don't want the team to doubt halfway through the Sprint on why such or such tasks were chosen over another!
2. Use online Priority Poker
In a usual situation - members are able to vote using markers on a whiteboard or poker cards.
However, this could be awkward in a remote situation.
You'll find yourself using the Zoom chat and count to 3 to ask for votes; engineers get influenced by each other and are not even sure what they are voting for!
I would encourage you to use one of the many existing Online Voting websites that offer a much better experience for this or my absolute favorite, airfocus Priority Poker.
3. Make it clear
Is your backlog looking like this?
No wonder it takes time to vote, even understand it!
Don’t let yourself be sunk into an unmanageable Backlog - I often tell my fellow PMs, show me your backlog, I’ll tell you which type of PM you are.
Imagine someone new coming to your backlog for the first time. That person will most certainly be lost!
So what to do?
I personally build a custom view of my sub-backlogs and try to organize it in such a way that it would make sense to anyone coming for the first time to understand what we’re up to!
4. Make it fun
One of the trends with a full remote situation is the accumulation of meetings.
We could talk about that on another topic, but the impact it has over your planning could be important, which is the topic at hand now.
Planning doesn't have to be the meeting where you just pick the task and put them into your next Sprint.
You can spice it up by:
Using a Planning Facilitator roter:
Prepare the Sprint Goal beforehand, and once the meeting starts let one of your team members lead the conversation during the planning! Not only will this show a great mark of trust in your team, but it will also boost the ownership spirit.
Giving Sprint funny names:
Each sprint, one of your members, will choose a funny name for the coming Sprint, could be strange animals, funny memes, etc.
5. Make it short
Looking at the length of a Planning Sprint. Based on my experience, for a team of 3 to 6 members, if the Refinement exercise has been done prior to Planning my suggestion is to have a Planning meeting of 30 to 45 minutes maximum (30 minutes preferred).
This allows time for Sprint Goal intro, Voting, and some debating. High-level the timing split should follow more or less this timeline:
3 to 5 min to review last sprint performance
3 to 5 min for the Sprint Goals
10 min for voting
10 min for debating.
If you find yourself looking at 1h long Planning sessions, I’d suggest reviewing your processes and identify anything that could be shortened.
Richard Giannetti
Read also
Experience the new way of doing product management
Experience the new way of doing product management