Mastering The Sprint Planning Meeting

So you’ve read the fundamentals about the Scrum Master role and you’re ready to plan your first Sprint. The Sprint Planning Meeting is probably your first real engagement with the Scrum Framework and you want to know how to make the best of it. Well let me share with you a few tips that will help them be short, sharp and, most of all, successful.

What is the Sprint Planning Meeting?

First of all – what is it? It might sound obvious but this is the session where the whole team will plan the upcoming Sprint. Technically it is actually part of the Sprint (usually it’s the first couple of hours) and that’s always been important for me. There shouldn’t be any gap between sprints. One finishes, the next starts.

The Sprint Planning Meeting is where the team figures out how much closer they can get towards the product goal. They might work out which items from the product backlog they can commit to getting done. Or they might simply craft a goal for the sprint and allow the actual detailed work to emerge over the course of the Sprint.

Before we get to that point though there is probably value in stepping back a little.

Before the Sprint Planning Meeting

The most successful Sprint Planning Meetings I have seen all tend to have a little bit of preparation beforehand. However, it’s so easy to do too much and that can seriously hamper not just the meeting itself but the value that the product and the team get out of Scrum overall.

“If you spend too much time thinking about a thing, you’ll never get it done” – Bruce Lee

Great Scrum Masters help their Product Owners prepare “just enough” for a Sprint Planning Meeting. But how much is “just enough”?

The aim of the preparation is to make the meeting itself run smoothly. We don’t want a whole team sitting around waiting for decisions to be made about the top priority items when this could have been decided quite quickly by one or two people beforehand. Equally, if it’s predictable that some questions are bound to be asked about one or two of the higher priority user needs then getting that information in advance is probably going to be a good use of time.

However, if the amount of preparation exceeds the potential wasted time by not preparing, you’re probably doing too much. There is almost an inevitability that at least some of the preparation won’t be needed as well so instead, one tip I have is “prepare to be unprepared”.

By that I mean having a few key sources of information at hand or ready to answer the phone should they be needed rather than spending time gathering that information in advance.

When we get good at Product Backlog Refinement this will help us immensely. Until then, my advice is to do slightly less refinement of the product backlog than you think is necessary and limit it to just the first couple of priority items.

Another valuable piece of preparation is to create a Definition of Done which we’ll cover in more detail in another post. Essentially the Definition of Done captures the constraints we must stay within when delivering the goal and the main outcomes we expect when evaluating whether we have been successful.

Define The Goal

One area of preparation that rarely turns out to be waste is the clarification of the vision of the product. Focusing in on any short-term goal we may have could become an inspiring Sprint Goal. If we can help the Product Owner craft a compelling vision of how the next increment of the product will add value then the need to specify the product backlog items diminishes. We can instead think at a higher level and creatively consider how we will work towards that outcome.

Imagine, for example I have a Product Backlog Item of “Make a cup of tea”. I could spend a long time working out the extra detail of how hot I want it, what kind of tea I want, whether I want milk and, if so, what kind and so on. However, if the goal of the Sprint were to “become comfortably warm” then we could look at different options of solving that problem (warmer clothes, electric blankets for example).

Try completing one of the following sentences when attempting to create your sprint goal:

• The aim of this sprint is to…
• At the end of this sprint, we will be able to…
• At the very least, by the end of the sprint we will have…
• Our users should look forward to the next sprint review because…

In fact this is going to form the first of five tips, that all start with D so let me suggest the concept of:

A 5D Sprint Planning Meeting

If we haven’t defined the goal in advance then I recommend spending a little time at the start affirming or reaffirming what this might be. A Sprint goal can be an amazing way to inspire the team, spark creativity and make the Sprint Planning Meeting more than just a Jira justle where the team tediously create sprint backlog tasks for Jira tickets.

So much more value can be added in a Sprint Planning Meeting. For example…

Destroy Dependencies in the Sprint Planning Meeting

A lot of the detail for how to do the work can be figured out after the Sprint Planning Meeting but if there are crucial dependencies that could torpedo the Sprint then spending that collaborative time to work them through and remove them wherever possible is usually time better spent.

A dependency is something that needs to be completed or solved before the thing we’re working on can be completed or solved. There are different ways that we can destroy dependencies:

Decouple

Not only is this a good simplification practice that also helps deliver in smaller increments, separating out the various pieces of functionality into their own specific containers reduces dependencies. This can be through introducing an interface or mocking or stubbing out the missing functionality, such as payment processing, until it can be added next iteration. For more on this, check out this article.

Deconstruct

By breaking something down to its basic components we can often see how our cognitive biases have led us to introduce dependencies where they don’t actually need to be. We may look at rewriting the feature so that it is sliced up in a different way, allowing fewer dependencies across iterations.

Another option is to deconstruct the workflow or development lifecycle and look at what skills we may be able to bring in to the team that allows the team to remove any external skill dependency and enables us to commit to complete delivery within our iteration commitment

Derisk

Dependencies are essentially risks to value delivery. They are parts of the development lifecycle that we are currently unable to complete right now that may have a big impact on whether or not we are successful in our ability to deliver value incrementally.

Maybe we can’t be sure we can actually decouple or deconstruct the dependency but we could still put a plan in place to reduce either the chances of the dependency causing us a problem or the impact it would have should the dependency become a real issue. Perhaps bringing that dependency into the remit of the team would help reduce the risk?

Detail

The last resort here is just to detail it out so that everyone is clear that there is a risk in the Sprint and we are heading into this Sprint clear about the situation. Firstly, add as much detail as you can to the product backlog item in terms of what you know, what you don’t know and your mitigation plan is. Secondly, visualise the dependency as much as possible.

Perhaps use different coloured cards for product backlog items with dependencies, perhaps link product backlog items that contain dependencies with string or draw out the dependencies on a whiteboard.Note. Don’t just assume that because you are aware of the dependency and its impacts, that everybody else is equally aware. Broadcast your findings widely and loudly and ensure that anybody directly affected is aware as early as possible and that communication channels are kept open throughout the iteration.

Draw Diagrams

Unfortunately I see too many teams trying to plan sitting down, or using a spreadsheet or other electronic tool.

The challenges that a team faces when planning a sprint are often quite tricky and require some creative thought.

It requires the team to consider impacts, consequences and alternatives, think through flows, processes and relationships.

When we stand up we are increasing the amount of oxygen flowing to our brain, we are more energised and see more possibilities.

When we draw or visualise in some way then we engage other parts of our brain that we probably don’t when looking at a spreadsheet or computer screen. That’s why I fully encourage teams to visualise as much as they can in their sprint planning.

There are many things that a team might find valuable in sketching out in a planning session. Perhaps they can sketch out a user journey to illustrate how a user might actually use this piece of functionality. In this case the team may model the user logging on, accessing their account details and drilling down into a particular report.

Or perhaps the team could map out the relationships of stakeholders that they will need to influence or interface with in order to make this sprint goal a reality. The team could cut out thumbnails of people from their organisation or use avatars then map out how everyone is networked within the organisation and what communication channels might be most effective.

Whatever the team is planning, I’ve yet to see a team be worse off by trying to visualise what they are thinking or trying to work through.

Discuss Options Before Deciding

We have a great collection of diverse minds in a Sprint Planning Meeting and it’s a shame that so few teams take advantage of this wealth of insight and creativity to explore options. Instead a solution is taken into the Sprint Planning Meeting and that team is simply asked to work out how to implement it.

Self-organising teams are often uncomfortable with the pressure of making decisions in sprint planning sessions and many people wish to avoid anything that resembles conflict. As a result, teams can find themselves falling into the trap of just agreeing on a way forward simply because it is the first suggestion that looks remotely sensible.

Sam Kaner, author of The Facilitators Guide to Participatory Decision Making explains that teams need to diverge before they converge but that it isn’t always as simple as that and the team will need to be guided through what he calls “The Groan Zone”.

The Groan Zone in the Sprint Planning Meeting

The groan zone is the point where the team tends to lose faith that a decision will ever be reached and anxiety levels at the lack of certainty are at their peak. It’s at this point that the team most needs reassurance and guidance.

My first step in this process is often simply explaining the concept of the groan zone to the team so that it is expected and the anxiety inherent in being in the middle of an unresolved decision is reduced.

Then my focus is on ensuring that no suggestion is judged prematurely as this will surely put others off from offering alternative suggestions. Ensure that all suggestions are accepted as possible and then enter a new phase of the discussion where ideas can be evaluated.

When it comes to deciding, there are many different levels of agreement that the team may be comfortable with.

The best facilitators help teams agree on a decision making process. From the simple majority voting where everyone votes either in agreement or disagreement and the most votes wins through to consensus where every single member of the team must be willing to support the proposal.

Kaner gives a number of principles of what he calls “participatory decision making”. In participatory decision making:

• Everyone contributes, not just the vocal few.
• People draw each other out with supportive questions. “Is this what you mean?”
• Each member makes the effort to pay attention to the person speaking.
• Each member speaks up on matters of controversy. Everyone knows where everyone stands.
• Members can accurately represent each other’s points of view – even when they don’t agree with them.
• People are encouraged to stand up for their beliefs.
• A problem is not considered solved until everyone who will be affected by the solution understands the reasoning.
• When people make an agreement, it is assumed that the decision still reflects a wide range of perspectives.

Perhaps suggest these principles to the team and ask how they would like to tailor them for their own bespoke decision making process. Once you have one way of making decisions, then you can review it and tweak it in the future.

Don’t Task Everything Out in the Sprint Planning Meeting

One myth with iteration planning is that teams must have every task identified, estimated and allocated to an individual before they can call the planning session complete.

The process of decomposing product backlog items into tasks and then, as a team, working out who will be working on which tasks is a valuable part of the planning process. This activity allows the team to determine whether or not they are committing to a realistic amount of work, whether there are any individual bottlenecks apparent and to assess the overall risk profile of the sprint.

However not only is it not required for agile teams to plan out everything in detail, in fact it can be counter-productive. Just as it is impossible to predict all of the requirements at the start of an agile project, so it is impossible to predict all of the tasks that will be required to be done at the start of an iteration.

Teams that attempt to use iteration planning to identify and allocate all of the tasks in sprint planning often fall into the following traps:

1. The meeting becomes incredibly dull and mechanical. The team stops looking at HOW they are going to solve the sprint goal and instead try and ensure they have covered all bases.
2. The perception is created that each team member now has a personal task list that will see them through the iteration. This can discourage collaboration as it implies that each person knows exactly what they are going to do.

Focus on the Team not the Individual

For example, if Jim has put his name on ten tasks, when he has finished task 3 with his name on it he will likely move on to the 4th task with his name on it without thinking about whether or not that is the most important thing for the team at that point in time.

The value gained from the Daily Scrum meetings where the team members assess on a daily basis what the most important things are to be tackled next is likely to be significantly undermined and the overall collaboration levels of the team are reduced.

Instead, I encourage teams to do just enough tasking out to answer the following questions:

• Have we taken on roughly the right amount of work as a team?
• Is any one person or group within the team over-stretched?
• Have we got a good enough picture of how these items are going to fit together?
• Have we got a good enough picture of how the design is going to evolve?
• Do we know where the risks are?
• Does everyone have a good picture of how they are contributing to the sprint?

Perhaps consider taking a regular poll to find the answers to some or all of these questions and when the team has reached a certain level of comfort (perhaps 80%) then ask the team if they would like to stop sprint planning.

What about you?

What tips do you have for mastering the Sprint Planning Meeting?

Download the free infographic here