How to Prepare for a Sprint Planning Meeting

This is a guest post by Nishi Grover Garg.

Scrum teams get together to decide on the work items for their next sprint in the sprint planning meeting. But is that the beginning of the conversation for the upcoming sprint, or are there some things that should be done before that?

Find out what you should be doing before your sprint planning meeting even starts so that you can help make the next sprint successful.

Prioritize the backlog

The first and most important consideration is to have a live product backlog that is up to date and prioritized with changing business needs. The product owner must have a constant eye on adding, removing, editing and updating items in the product backlog. When the time approaches to get into planning the next sprint, the product manager must bring to the table a list of the highest-value items that the team can pick from.

Modern Test Case Management Software for QA and Development Teams

Research features

Since most agile requirements are brief — either in the form of user stories or just sentences listing the features needed — they require some detailing to be implemented. The product owner must spend time researching each of the features and trying to lay out in simple terms the actual need they each describe. They may use bulleted points or simple sentences to explain the feature in some detail. We see this happening mostly during or after the sprint planning meeting, but if any requirements are known before the meeting, the product owner can get a head start.

Decide on a definition of done

During a sprint planning meeting, typically the team picks what they will do within the sprint and deliver by the end of that iteration. It is imperative that they know and agree upon a definition of done that defines each user story as well as every task within that user story. Be it a development task, a test design or execution task, or a review task, everyone must concur on a common understanding of what “done” means in order to ensure a smooth delivery and no conflicts at the end of the sprint.

Groom user stories

Each user story that is brought forth for sprint planning must be groomed, expanded upon and detailed with the entire team’s knowledge and input.

When the testers, developers and the product owner sit together and discuss a new feature, many new questions may arise from the team. Questions often center around integration with existing features, how the feature may behave in specific cases, or how the behavior must be for different types of users. Special cases also form a part of the acceptance criteria that are defined within the user story to make it complete.

Whatever the questions, it is best to have them arise earlier and answer them before picking the user story. Basically, this means a conversation has to happen for each user story, so that the team can gain an understanding and decide on confirmation criteria defined and accepted by all.

These story grooming sessions should happen before the sprint planning meeting so that during the planning, the team knows exactly what is required from that feature and can give better estimates and story points based on its complexity.

Start with design

Many user stories need visual storyboards or mockups of the user interface, and in these situations, UX designers may need to be involved. These stories must be picked up one sprint ahead and allocated first to the designers, so they can have the mockups or screen layouts ready before the feature is picked for development in the next sprint. This approach makes communication easy and avoids any lags or delays during development.

Similarly, some user stories may require research into a new approach, technology, or tool before getting started on it, or there may be a need to create a complete architectural design for a certain area before jumping into its implementation. For such cases, the design or R&D task must be created and started in a previous sprint, then allocated to the senior developer or architect within the team to get these relevant designs and research findings ready. They can then share this information with the team so that everyone is ready to begin work on the implementation in the next sprint.

A product owner must be on a constant lookout for user stories that may need design or research work done before beginning them. Have these stories distributed to the relevant people the sprint before to ensure that implementation will be smooth and delivery can take place on time.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform


Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.

In This Article:

Try a 30-day trial of TestRail today!

Share this article

Other Blogs

Key Factors to Consider When Selecting the Right Test Case Management Tool
General, Software Quality, TestRail

Choosing the Right Test Case Management Tool: Key Factors

Understanding the need you have is often the first step in defining the method for managing test cases that will work for you and your team.

Understanding QA Roles and Responsibilities
General, Agile

Understanding QA Roles and Responsibilities

The software development process relies on collaboration among experts, each with defined roles. Understanding these roles is crucial for effective management and optimizing contributions throughout the software development life cycle (SDLC). QA roles, respons...
DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC
General, Business, Software Quality

DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC

Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.