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 organized 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/prioritize 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 organize. Bring the backlog to order The Product Owner is responsible for collating and organizing all backlog items that could be worked on during the sprint and is typically referred to as . They may do this alone or at a pre-meeting before the planning and aim to break tasks down into actionable items. backlog grooming 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 that there is an inherent contradiction in ownership and decision-making in a Scrum mentality regarding . He asks: asserts technical debt “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 maximize 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 prioritize 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: 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. 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. 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 and you can also use prioritization features. prioritizing tasks in your product backlog Stepsize’s 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! Previously published at https://www.stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

ATLASSIAN

Velocity

Track and prioritise technical debt. Create your free account at stepsize.com

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Frontend

2022 - HackerNoon Contributor of the Year - Refactoring

Get the AI companion for software projects. Never miscommunicate again

Nominated for 2022 - HackerNoon Contributor of the Year - Frontend

Nominated for 2022 - HackerNoon Contributor of the Year - Code Quality

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Effective Sprint Planning: How To Not Get Overwhelmed By Technical Debt 

Effective Sprint Planning: How To Not Get Overwhelmed By Technical Debt

Too Long; Didn't Read

Companies Mentioned

Alex Omeyer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Effective Sprint Planning: How To Not Get Overwhelmed By Technical Debt

Too Long; Didn't Read

Companies Mentioned

Alex Omeyer

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES