How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work

There are plenty of posts that tell you that sprint planning should include things like shaking hands, making pledges, and a team song (I wish I were joking). This is not one of them. Nor am I advocating for you to buy into any particular school of thought (i.e. Scrum vs Agile) or suggesting that you need to sign up to someone’s downloadable program for $XX, the author of which will haunt your inbox forever. 

Instead, I want to offer practical strategies to make planning a Sprint less painful so that you feel organised rather than overwhelmed and have achievable goals rather than just another staggering list of to-dos. A successful Sprint should leave you feeling like you’ve worked on things that are important and worthy of your time.

What is the purpose of a sprint planning meeting? 

The purpose of sprint planning is to define what can be completed during the next sprint and decide how the work will get done and by who. This included reviewing any leftover tasks from the last sprint and creating a plan of action for these as appropriate.

Sprint planning attendees

Scrum Master*/Sprint leader

The Scrum Master is responsible for setting up the infrastructure for the sprint planning meeting (zoom meeting/room booking, etc.) and managing timekeeping during the meeting to ensure that everyone is aligned on the goals of the upcoming sprint.

Side note: I am using this term as I understand an agreed-upon alternative is yet to be decided upon in the world of Scrum.

Product Owner

The product owner arguably does the bulk of the pre-Sprint meeting work. They prepare the list of product backlogs to choose to work on/prioritise during the sprint and facilitate discussion on the priorities of the sprint.

Development team

These are the vital people that will be doing the work during the sprint - think devs, designers, test engineers etc.

Before the meeting

Sprint planning is about gathering the necessary people together to determine the product development goal and work you will do in your upcoming sprint. But before you get to a planning meeting, there’s a reasonable amount of prep you need to do to organise.

Bring the backlog to order 

The Product Owner is responsible for collating and organising all backlog items that could be worked on during the sprint and is typically referred to as backlog grooming. They may do this alone or at a pre-meeting before the planning and aim to break tasks down into actionable items. 

Be clear on team velocity and capacity

Consider the amount of work that participants can successfully complete during a sprint. Consider the achievements of previous sprints as a way to measure team velocity. What tools and skills are needed to achieve the work? Who is available to work on the sprint? 

Define your sprint goal

Determine the aim of your sprint and what you want to have achieved at its end. Writing this down is helpful to offer clarity to not only team members but other stakeholders outside of the sprint also.

Make an agenda for your sprint planning meeting

The common view is that planning a 2-week sprint should take about four hours. Map out the agenda of the meeting accordingly. There are plenty of sprint planning templates around if you don’t have one already, for example:

• Smart sheet
• Atlassian 
• Fellow
• Planio

What about technical debt and sprint planning? 

Stefan Wolfers asserts that there is an inherent contradiction in ownership and decision-making in a Scrum mentality regarding technical debt. He asks:

“If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximise the value customers derive from the Development Team’s work. 

The Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?”

It is vital to make paying down technical debt - including tasks such as code refactoring and bug fixing - a priority of every single sprint. Bug fixing feels like a never-ending loop if you have a high level of debt, and a sprint can unearth even more bugs. Focus on the bugs you have committed to deal with and add those you find (unless incredibly urgent) to the bug backlog for your next sprint. 

Your team also needs an agreed-upon definition of Done to avoid more technical debt sneaking in.

How to include technical debt into your sprint?

Instead of having a dedicated technical debt sprint every quarter try a more sustainable approach of spending 10-30% of every sprint dealing with the most important technical debt.

It’ll help you prioritise the tech debt that's in the way of upcoming features on the product roadmap. (If you want to learn how a modern team at Snyk has achieved it, check out this case study.)

Here are 3 steps that’ll help you incorporate technical work into your usual sprints: 

1. Make technical debt visible 

Start with highlighting, bookmarking and creating technical debt issues. You can easily do that with the Stepsize VS Code or JetBrains extensions.

2. Determine the business impact of each debt item

If you have a difficult time convincing your management to work on technical debt, try focusing on the business impact instead of technical problems. E.g. mention how fixing this debt will reduce the number of support tickets or help you reduce the time-to-market.

3. Bring it to your sprint planning meeting

Once you've created technical debt issues and described their business impact, bring it up during your next sprint planning to discuss with the team.

Deciding what technical debt to focus on in your code sprint is comparable to prioritising tasks in your product backlog and you can also use Stepsize’s prioritisation features.

Remote work planning 

How we work is constantly changing. Many traditional Sprint planners talk about whiteboards (digital or otherwise) and getting everyone together in the same room. We know that’s often not just practical with distributed teams. 

Where possible, avoid a hybrid model where a chunk of the team is together and the rest distributed unless you have good practice doing this successfully. Otherwise, what tends to happen is that those who are physically present make group decisions, and the input of remote people is more of an afterthought. 

Online tools (see upcoming article) are critical to ensure that everyone gets an equal seat at the meeting. Be especially aware that remote meetings are more draining than in-person meetings and plan accordingly with breaks and keeping things focused. 

Reward your team

Sprints are more pleasurable if there’s something to look forward to - if budget allows, consider getting some catering in or delivery orders to people’s homes for remote workers to celebrate the end of a sprint. Even if a sprint is commonplace in your company, everyone likes thanks. And don’t forget to celebrate the tech debt heroes who have done behind the scenes work!