The Role of QA in Sprint Planning

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.

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 follow-up 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 this guide for 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.

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. 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 fast 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 this guide on Writing Test Cases Without Requirements).

4. 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.

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.

Summary

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.

This article is a republication of an article that was originally posted here.

Wes Silverstein
Wes Silverstein is the founder of Mindful QA. He has provided QA testing, user experience, and Agile consulting for over 100 clients for websites and mobile apps across all major industries. Over the past 10+ years, Wes has worked with companies ranging from tech giants to healthcare, education, media, digital agencies, non-profits, start-ups, and many more. He was named one of the “Top 50 Visionaries in Tech” by The Internet Conference, and nominated for Testing Manager of the Year by the American Software Testing Conference. Originally from the San Francisco Bay Area, Wes now lives in Los Angeles with his wife and dogs/cat. When he’s not diving into all things Mindful QA, he plays music and writes.

The Related Post

There are so many aspects of any job that they don’t teach you about in school, and the Software Engineering field is no different. This is a collection of lessons learned in 5 years as a Software Engineer that are applicable and valuable for anyone to know in the software and technology fields. It took ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe