How to prepare a productive sprint planning session

Despite each scrum team being unique and every project different, we still seem to face the same old problems when it comes to the development cycle. Among the most common is the planning session. When it’s long. When it’s unproductive. Reasons may differ, but here I’ll try to cover a few main ones in addressing the question: What should a product owner do to be best prepared for productive sprint planning?

Sprint planning according to the scrum guide

Sprint planning is an event or ceremony during which a scrum team sets two main objectives: to articulate the sprint goal and to identify those unfulfilled project backlog items (PBI) that keep the scrum team from achieving this goal. Although the team may be accountable for the successful completion of sprint planning,  even the most experienced cannot do this without well-prepared artifacts. In scrum theory, however, a product owner is responsible for prioritising the product backlog, yet in practice, this has shown to be a  task better suited to collaborative efforts. 

Scrum master expectations

The first thing you should expect in a planning session is a  team not doing any actual work. In my opinion, team members should not focus on specifying tasks, nor on their acceptance criteria, nor on their definition of ‘done’. This is particularly relevant when an estimation of required effort for task completion is not mandatory. Only when a responsible member does not fully understand what work is necessary should this be considered. Otherwise, defining the sprint goal is the first obligation in any planning session. Although this goal is commonly connected with setting up the environments, workflows, and internal processes in the team, it is also good practice to include at least one functionality according to what defines it as being ‘done’. In later stages, sprint goals are typically related to finishing particular modules or sets of functions. Depending on how a product owner organizes backlog sprint goals, these may or may not be aligned with achieving successive milestones.  

The next step is in specifying what work needs to be done to achieve this goal. Here is a common point from which many beginner scrum masters attempt sprint planning. Though task selection seems to be the essence of planning, we should really consider it as the outcome of everything we’ve done previously. For developers, it is convenient to claim a particular task is connected to a module they’re working on so that they may take responsibility for it and proceed. Calculation of cumulative effort through story points seems simple in terms of team velocity, however, experience shows this does not bring value to planning. By selecting tasks in direct accordance with the sprint goal as defined, team members can perceive them from a greater vantage point and in doing so, recognise factors not included in their original descriptions. Moreover, owing to the general imperfections of backlog, and to situations where the product owner is unable to recognise a requirement for additional work, this becomes a crucial factor in sprint planning. Finally, since team members with more developed technical knowledge will now have responsibility for these particular backlog items, the opportunity for a seamless transfer is particularly good. Here, in fact, is the essence of planning: a development team committing itself to the sprint goal through the completion of those backlog tasks that are required to achieve it. 

Managing PBIs for a smooth transition 

In theory, we need a backlog; in most cases, also knowledge of team velocity. But for a scrum master to be effective, he or she must be mindful of the desired outcome. This is backlog refinement. Backlog refinement is the process of creating a backlog, managing its form, and ensuring a common understanding of it. There are as many ways of managing backlog as there are product owners - perhaps more. But I’ll share the one that works best for me. When looking at the application, you can divide it into simple modules and, with a bit of experience,  estimate or compare the workload needed to deliver them. This way, you can prepare a more detailed roadmap for the project. Or, should the project be big enough, one for its present phase only. If you don’t have experience in preparing roadmaps, there are dozens of tutorials online showing how to do so. But remember: when creating a project plan, always expect the unexpected.  So it’s crucial you advise stakeholders this roadmap is sure to undergo regular updating throughout the project.

A roadmap sets our milestones. Milestones set our sprint goals. What about the tasks?

When dividing modules or milestones into tasks, be mindful of granulation. Creating one task for a week’s worth of work will not be specific enough, nor will you be able to measure progress by dividing it by 100. You would spend too many hours writing it and your development team too many in tracking their statuses. Common practice is that each task takes less than 8 hours to deliver - though this be no rule. Dedicated practice is that which leads to setting proper granulation. 

The underestimated importance of common understanding in PBI management 

People often assume it’s enough to note acceptance criteria. In theory, it is. However in my experience, when defining acceptance criteria, there will always be some aspect that goes overlooked. This is why it's important that your team be made aware, that it understands, and that it consents. By encouraging team members to contribute to the backlog, this is more easily achieved. An active part-taking in its creation provides an intimate understanding.  

All going to (sprint) plan

In my experience, a sprint planning session should take no more than 3 hours. This is a case of proposing a sprint goal whose route to achievement is already understood and understood by those who helped create it. Furthermore, development team members are typically more likely to meet this goal when they are aware of the commitments they have made. 

NB:  I purposefully chose not to comment on task estimations by team members nor on specific techniques such as planning poker.  According to the scrum guide, these are not mandatory and for more experienced teams, unnecessary. 

Would you like to know more about preparing a productive sprint planning session? We’d be happy to help. Write to us at hello@start-up.house