How to Conduct a Remote Sprint Planning Meeting?

There are no definite answers for such a question in a complex environment.

With that being said, I believe we can benefit greatly from learning not only from our own successes and failures but also by sharing the lessons learned with others. Below you will find a short story of a reasonably big Scrum team.

So let me tell you a story about the planning call in one of the teams I had an opportunity to work with. We were developing a new product, innovative in a few ways, but not full R&D - so we decided to start with the Scrum framework, just slightly adjusted to the Netguru way.

The context of our remote sprint planning meeting:

• Product Owner on the client side, Scrum Master on the software house side

• 2-week sprints

• A 1.5 h time slot for the planning of each sprint

• Dev Team: 6 developers, half on our side, half on the client’s + a QA specialist

• Fully remote team

Challenges that we faced during the first remote plannings:

• During planning in a 4+ person team we often need a smaller discussion - how can we do it remotely?

• The team doesn’t have enough time to estimate properly

• The team doesn’t have the time to digest the plan, stories, goal, etc.

We learned that what we really need to have a good plan for the next sprint is:

• A shared understanding of business priorities - what should we tackle next (that’s the PO’s job)

• Estimated development tasks that cover the scope of our business goal (we use grooming meetings to achieve that one)

• Awareness of the current state of the project - what is finished and working, what is not

• Awareness of our capacity for the next sprint (any days off or holidays?)

And now - the key insight of this article - the planning process we established after 7+ iterations, step by step.

• A grooming meeting was held a few days in advance, during which the Dev Team and the PO had a chance to discuss features (user stories) that will be the next priorities. During or after the grooming, the features are split into development tasks.

Now we are ready to start the call. My job as a Scrum Master is to facilitate the planning - below you can find steps that are my current planning agenda.

1. The PO communicates business priorities - that’s an early version of our future sprint goal.

2. The Development Team makes sure all those priorities are split into development tasks. That’s where we need close cooperation between team members to make sure we thought about all the dependencies. It’s a good practice to note down dependencies or mark them in Jira - we will need this information later on. At this point, our solution is to split the meeting into separate calls in smaller groups - sometimes feature-focused, sometimes with subject-matter experts.

3. The Development Team checks its capacity.

4. The Dev Team fits the tasks into the capacity to see if we have some room left or it there is too much to do.

5. Velocity check. Based on historic, the data team assesses how much they can take into the sprint. Based on that the Development Team prepares a suggested sprint backlog.

6. The first version of the sprint backlog is presented to the PO, he or she may change the order of priorities or ask to exchange some items (“oh, if we can’t have the admin panel feature this sprint, then it’s better to focus on UI improvements than more accurate statistics”) - just as there are dependencies on the technical side, there are some on the product side as well. ;)

7. When we have buy-ins for the sprint backlog, the PO suggests the final wording of the sprint goal.

8. It’s time to start the sprint in Jira and discuss the exact plan for the next few days. Do we have any specific dependencies this sprint? Is there a risk somebody will be blocked?

9. Now we are ready to adjourn the planning meeting and close the call. Your team just did something great - thank yourselves for the meeting and for the attention you paid to your work. Now you have a shared goal for the next sprint - go get it!

Key takeaways:

1. Take you time to prepare before the sprint planning meeting. This is even more important when the meeting is remote - on a call, all impediments caused by lack of preparation have a double impact.

2. Be aware of what kind of input you need - having time for preparation is futile if you are not sure what you need to prepare for.

3. Share the main agenda and meeting goal noted in a place the Development Team can easily access.

4. Forge a clear and shared understanding of the expected outcome of the sprint planning. From my experience, the best approach is to have a goal written down at the beginning of the meeting and make the Development Team (the Team, not the PO, not the SM, not some manager) see this as their goal for the next 1.5h. I personally use sprint planning questions suggested by Lyssa Adkins in Coaching Agile Teams.

Remaining challenges - our opportunities for further improvement:

• Overcommitment - our flow resolved problems like “I don’t know what should I work on” & “Which backlog items are the most important from the product perspective”. Our next challenge is to deliver working increments at a predictable pace.

• Asses our velocity based on data (I know, I know, basics, right?).

• Harness the power of backlog refinement: coach the PO to prepare a backlog for the planning and to use refinement in the most efficient way.

This flow worked in our environment and is helping us achieve better results in a less stressful way. Remember to first observe your environment and team - and then experiment and see what works for you. I hope this article will be an inspiration for a change in your process - please share your thoughts, experiments, and findings in the comments.