How to conduct efficient sprint planning

My learnings after delivering over 10 IT projects

Every project is unique and to maximise your chances for the best outputs tailor-made planning session might come in handy. Scrum tries to offer a blueprint for such meetings, but from my experience, it’s better to adjust best practices to your needs and customise if needed. In this article, you’ll learn how to prepare for Sprint Planning, how to lead the meeting and how to solve the most common problems.

Before Sprint Planning

Good preparation for the planning means you’re halfway there. Here, I assume, our backlog is well-defined thanks to a productive Backlog Refinement session (See my article about this meeting) and we have a lot of learnings from the recent Sprint Retrospective (Read more about best practices for Retro here).

• Schedule a recurring meeting with clear agenda — the meeting should be held regularly, on the same days, preferably from Monday to Thursday
• A Sprint should be 2-week long (Consider 1-week sprints If your project is really dynamic or 3-week sprints If the scope is very predictable)
• Reserve 1 hour for the meeting per 1 week (2 weeks = 2-hour meeting) — Use it as a rule of thumb and adjust after several meetings If needed
• Don’t schedule the Sprint retrospective and the Sprint planning meeting together. Give the team enough space to digest the information acquired during the retrospective to contribute to Sprint planning effectively. For example, you can insert a team lunch in between
• Make sure that the product roadmap is up-to-date, visible to the entire team, and that epics and versions are listed correctly in Jira before your Sprint planning meeting
• When a particular item has been completed partially, but the feature can still be deployed, split the backlog item into two cards. The incomplete part of the task should be moved to the To-Do column
• Finish the previous sprint. Depending on your workflow you can analyse team effectiveness so you will get more insights for the next meeting.
• Organise tasks in the next sprint as probably all issues which were not finished are scattered randomly in the next sprint’s task list. (or you can send them to backlog — more radical approach)

Potential data to measure the effectiveness of a team:

1. Velocity = number of points delivered in a Sprint.
2. Average Velocity = average number of points delivered per Sprint.

During the planning meeting:

• At the start of the meeting, present any relevant action items from the team’s retrospective
• Give product or market updates so that everyone is on the same page and has a broader context fresh in their minds
• Propose a Sprint goal [short description (1–2 sentences) of what the team is going to complete over the course of the Sprint]
• Start from covering sprint goals by listing all required issues in the top section of the backlog
• Later on, go through the backlog and make sure that tasks related to sprint goals are in the sprint
• Think about other important topics despite sprint goals — is there anything your team is obliged to deliver? Maybe some cross-team dependencies?
• Review unfinished tasks from the previous sprint and decide if they should stay within the next iteration
• The priority of stories in the backlog should be descending — from the most important on top
• Let everybody assign to issues and see if people are willing to take more tasks or you should move some issues back to the backlog
• When assigning issues, considerer these 3 factors: public holidays, personal vacations, and team or company-wide events

Working with stories during the planning meeting

The planning session is dedicated to setting goals and organising issues. Make sure you’re not defining tasks on the go.

• If you’re not sure about the given issue, check the story’s definition — has it changed since it was written? Is there new contextual information the team needs to consider?
• Is the story’s estimate still valid? Does the entire team agree on the estimate? If not, re-estimate it.
• What tasks are required to complete this story? Use sub-tasks and checklists to help parallelize work and optimize the flow. If the team members find unique stories as they break down work, promote these tasks to fully independent stories.
• Are there any special skill sets required? How can we optimize the specialist’s time without blocking the rest of the team?
• Are there any dependencies between stories? Can we complete all of the work during the Sprint given those dependencies?

TIP: Team engagement and morale will naturally fluctuate from Sprint to Sprint. These variations often show up during Sprint planning, but resist the temptation to dig into it right then and there. Instead, use the team’s retrospective to understand any issues that are impacting the team morale. Teams that respond quickly to culture and development concerns are happier, more productive, and write better code.

Common problems during planning:

• Creating a task description takes a lot of time, and other team members are just waiting and not providing any output —if occurs, invest more time for backlog refinement
• During the planning session, the team discovers new scope that could significantly increase the amount of time required to complete a specific user story — when facing such an issue circle back to backlog refinement meetings. Think about creating research tasks to better understand the upcoming work.
• Developers report difficulties with estimating tasks — depending on the project phase you can use historic data to better understand the team's performance.
• Too much pressure on hurrying up, as Scrum events take developers away from coding — always emphasise that going in the right direction is more reasonable than making features that nobody wants.

What are your problems when conducting such meetings? Let me know in the comments or contact me If you have any questions regarding scrum ceremonies.