How we run visual sprint planning meetings

Last week Peter wrote about advantages of running a visual sprint planning. But what is visual sprint planning? And how does it work in practice? Let’s have a peek at how we, at Qualdesk, use a digital whiteboard to make our planning visual... and therefore better.

When it comes to sprint planning there is one main goal – agree what the team is working on for the next sprint. But there are different things you can optimise the process for.

You can do planning as fast as possible, so the team can spend more time building things. Or you can ensure that stories are perfectly sized, so you finish them all within the sprint.

At Qualdesk, we decided that what’s most important is enabling every team member to impact the plan, share their opinions and propose what we should be focusing on.

Using a multiplayer whiteboard is at the core of this (not only because we’re building one) because you can’t expect people to be fully engaged if all they get to do is watch someone else sharing their screen. So, putting all our work and conversation into an environment where everyone can “touch” it massively helps with encouraging people to take part.

But there is a bit more to it.

Step 1: Create a public space for sprint candidates

Before our sprint planning meeting, we put all the candidates for the next sprint onto a shared Qualdesk board. It is easy to access by everyone on the team as it is organised into a team workspace on Qualdesk, which means that anyone can put things onto the board at any point in the sprint (although, to be fair, most of the putting happens the day before the sprint planning).

Apart from regular groups of issues like “things left over from last sprint” or “bugs for next sprint”, anyone can put proposed Epics, UI improvements, questions or issues based on feedback from customers.

We put everything into Qualdesk groups, which later become the structure we use to organise our conversation. Usually, we end up with a board with following groups:

• three or four groups representing different Epics with their subissues
• things from last sprint
• selected bugs
• UI improvements
• small issues from the backlog

We specifically split out the bug selection conversation from sprint planning into a separate “bug grooming” session, run by engineering team where we discuss reproducibility, potential fixes and how critical it is, afterwards deciding if that should be

This means that before we even start the sprint planning meeting, everyone has a complete picture of what we will be talking about.

Step 2: Open conversation

Time for the unstructured, organised chaos part of the process. We all join a call and go onto the board and... we discuss the groups above, one by one.

We don’t do it in any particular order – sometimes we even stop discussing a group halfway through if the conversation takes us in such direction.

Whoever added the group presents the rationale behind it, and we make a decision on whether or not to include it in the sprint based on

• what we’ve already agreed should go in the sprint
• what we’ve heard from customers
• our longer-term priorities
• the effort required to deliver a viable version of what’s in the group (this sometimes involves removing things from the group, or splitting a group into two ‘releases’)

We don’t vote, we don’t estimate, we just discuss, because at our size it’s the quickest way to reach an agreement. This is when Step 3 comes in.

Step 3: Immediate commitment (agreements as data)

As soon as we have agreement about what should happen with a group of items, we immediately change the data in the system of record (in our case, Jira). We add them to the next sprint, the sprint after, or move them back to the backlog. Sometimes we also use this time to restructure stories, change epics and assign ownership.

This saves us a huge amount of time. Instead of one person having to note down or remember what we agreed and then spend time, after the meeting, writing it up, we save those agreements as data in Jira straight away, literally with a few clicks.

Summary

This method of running sprint planning helps us achieve the goal of getting everyone involved, having their voice heard and having direct impact on what and how we build. Even though speed wasn’t our highest priority, I believe this method makes for very quick sprint planning meetings (there are quicker methods, but without similar levels of team’s involvement)

A small disclaimer: the methods we use might not work one-to-one in your case – we are a team of 5, so we can afford to do things in a less structured way. However, I hope these can inspire you to make your own meetings better too!

If you found it useful or it sparked some thoughts, don’t hesitate to tweet me @lukaszsagol. And if you are curious about how Qualdesk can make your planning meetings better sign up or get in touch for a one-to-one chat about how to run your sprint planning in visual environment.