The Role of QA in Sprint Planning

Sprint planning is something that every Agile team does. But when each team has different needs, there isn’t always a “one size fits all” strategy. As a consequence, it’s not always clear what the role of QA should be. Should QA be an essential part of the Sprint Planning process? Or should testers just be told to look at the Jira board and comprehend the deadlines? Read on to understand how the role of QA can – and should – fit into the Sprint Planning process.

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

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

Some tickets in the sprint will also need advanced planning from QA. For instance, they may require to write test cases, examine design files, or ask follow-up questions. QA will be more ready if they know which tickets are in a sprint from the start– instead of near the end.

Top 5 Reasons to Include QA in Sprint Planning

1. Estimates

Estimates aren’t only for developers – or at least they shouldn’t be. After all, for each ticket an engineer requires to finish in a sprint, QA must also have time to test it. By giving estimates for tickets in every sprint, testers can help weigh in on which characteristics and/or bug fixes can fit in the timeline. 

2. Acceptance Criteria

As most testers have encountered, “new feature” tickets are usually pretty bare bones. Seldom a ticket will only have a title and a very brief summary. This may be sufficient to get a general idea of what the feature is. However, it’s normally not enough information for truly thorough testing.

For instance, imagine a ticket entitled, “Add embedded video player.” The summary might state 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 usually require more specific acceptance criteria in order to ensure the feature is truly performed as intended.

If you’re not familiar with acceptance criteria, basically it’s a list of functionalities or other details that the feature should have. Some of the information testers might require in the above situation could include:

• Should the video player have a closed captioning option?
• How many seconds should the “jump ahead” button fast forward?
• Should the user be capable to full-screen it?
• Are the videos supposed to be hosted on the company’s standard YouTube, Vimeo, or somewhere else?
• Is there a design file that the video installation should match?

When QA is included in Sprint Planning, testers can instantly identify which tickets need more acceptance criteria. When this is performed early on, product managers will have time to append additional details. If QA isn’t informed of the lost info until the ticket is ready to test, the launch itself could be delayed.

3. Test Cases

Given the face speed of Agile software development, there isn’t always time for QA to write test cases for each new feature. Even with QA included in Sprint Planning, that might still be the case. But when testers can have a chance to get familiar with all of the tickets in a sprint from the start, it’s significantly more likely that they’ll be able to write at least some kind of test cases. This can even be the state when, as detailed above, acceptance criteria is missing. 

4. Device/Browser Coverage

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

When QA has a part in Sprint Planning, they can advocate for and propose specific device/browser coverage for each ticket in the Sprint.

5. Prioritizing

It’s a reality that even with excellent planning, seldom a team can’t meet the original Sprint deadline. Since QA is the ultimate step in completing each ticket, it’s usually the testing time that gets cut off at the end. Sprint Planning can be utilized to prioritize tickets and make backup strategies in the event that not everything is achieved in time. It’s important for testers to be informed of which tickets are the most – and least – significant.

Conclusion

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

Our skilled QA’s are well-versed with the latest tools and technologies. We, at TestUnity, have helped many companies assure unmatched performance with our all-rounding testing services. For reliable and exceptional testing services, TestUnity is your one-stop solution. Get in touch with us here.

TestUnity

Testunity is a SaaS-based technology platform driven by a vast community of testers & QAs spread around the world, powered by technology & testing experts to create the dedicated testing hub. Which is capable of providing almost all kind of testing services for almost all the platforms exists in software word.