Sprint planning is something that most Agile teams do. But when every team has different needs, there isn’t always a “one size fits all” approach. As a result, it’s not always clear what the role of QA should be. Should QA be an integral part of the Sprint Planning process? Or should testers simply be told to look at the Jira board and follow the deadlines? Read on to find out how the role of QA can – and should – fit into the Sprint Planning process.Three people in a meeting with laptops open

First things first. Does QA even have a role in Sprint Planning? After all, the everyday answer at many companies may be “no.” But to have the best software development and Agile process possible, it should be “yes!”

QA only has a finite amount of testing time per sprint. So it’s a good idea to make sure testers can provide full test coverage for all tickets in the timeline.

Some tickets in the sprint will also require advanced planning from QA. For example, they may need to write test cases, review design files, or ask followup questions. QA will be more prepared if they know which tickets are in a sprint from the beginning – instead of near the end.

Top 5 Reasons to Involve QA in Sprint Planning

1. Estimates

Estimates aren’t just for developers – or at least they shouldn’t be. After all, for every ticket an engineer needs to finish in a sprint, QA must also have time to test it. By providing estimates for tickets in each sprint, testers can help weigh in on which features and/or bug fixes can fit in the timeline. To learn more, check out our guide to QA Testing Estimation Techniques.

2. Acceptance Criteria

As most testers have experienced, “new feature” tickets are often pretty bare bones. Sometimes a ticket will only have a title and a very brief summary. This may be enough to get a general idea of what the feature is. However, it’s usually not enough information for truly thorough testing.Two cartoon people standing next to a sheet of paper titled "Rules" and numbered from 1 to 3

For example, imagine a ticket entitled, “Add embedded video player.” The summary might say something like, “Add a video player to screens that have audio clips.” That information could be clear enough to other roles, such as project managers. But testers generally need more detailed acceptance criteria in order to make sure the feature is truly implemented as intended.

If you’re not familiar with acceptance criteria, essentially it’s a list of functionalities or other details that the feature should have. (Learn more in our full guide to acceptance criteria.) Some of the information testers might need in the above scenario could include:

  • Should the video player have a CC (closed captioning) option?
  • How many seconds should the “jump forward” button fast forward?
  • Should the user be able to full-screen it?
  • Are the videos expected to be hosted on the company’s official YouTube, Vimeo, or somewhere else?
  • Is there a design file that the video placement should match?

When QA is involved in Sprint Planning, testers can quickly identify which tickets need more acceptance criteria. When this is done early on, product managers will have time to add the additional details. If QA isn’t aware of the missing info until the ticket is ready to test, the launch itself could be delayed.

3. Test Cases

Given the face pace of Agile software development, there isn’t always time for QA to write test cases for every new feature. Even with QA involved in Sprint Planning, that might still be the case. But when testers can have time to get familiar with all of the tickets in a sprint from the beginning, it’s significantly more likely that they’ll be able to write at least some form of test cases. This can even be the case when, as detailed above, acceptance criteria is missing. (Learn more in our guide on Writing Test Cases Without Requirements.)

Woman sitting next to three device screens4. Device/Browser Coverage

A big part of QA testing apps and websites is determining which browsers/devices should be tested. This can vary depending on the specific feature or bug fix being tested. For example, if there’s a new feature targeting people under 30, it’s less likely that it will be used on IE 11 (Internet Explorer). On the other hand, it will almost definitely be used on iOS 14.

When QA has a role in Sprint Planning, they can advocate for and plan specific device/browser coverage for each ticket in the Sprint. Learn more in our guide to cross browser testing.

5. Prioritizing

It’s a reality that even with excellent planning, sometimes a team can’t meet the original Sprint deadline. Since QA is the last step in completing each ticket, it’s often the testing time that gets cut off at the end. Sprint Planning can be used to prioritize tickets, and make backup plans in the event that not everything is completed in time. It’s important for testers to be aware of which tickets are the most – and least – important. This can also help guide user acceptance testing at the end of a sprint.

The Role of QA in Sprint Planning

The above are only a handful of the many reasons that it’s beneficial to give QA a role in Sprint Planning. But each reason is significant, even on its own – let alone when combined with the rest! There are many ways for QA to play a role in Sprint Planning. Each team can find the way that works best for them. But ideally, QA should always play some role in Sprint Planning – or you may end up with a Sprint that’s not truly planned out at all.