“Niagara Falls has traveled 7 miles upstream in the past 12,000 years. Let’s grow our user traffic at a faster rate by wisely involving QA.”

Grooming and Sprint planning is something that most Agile teams do. But it’s not always clear what the role of QA is in these. What should a QA do during the Sprint Planning and Grooming process? Should testers simply be told to look at the Jira board, check the acceptance criteria and then do the testing of sprint stories.

As a tester I actively try to be involved in these 2 processes as its my first opportunity to assess the requirements and the information provided. Some typical thoughts that come into my mind when I am in a grooming/planning meeting are as follows.

• Do I understand the requirements?
• What requirements have not been written down?
• How can I test this work? Is it even testable?
• Do I need any additional configurations/ test data to test this.
• Do I have any dependencies in order to test this.
• Which all platforms should I cover this with?
• Will this be beneficial to an end user?
• What all possible scenarios could occur from a user point of view?

1. With these questions in mind let’s see What should a QA do during Grooming.

   1.1 The Importance of Acceptance Criteria

   Acceptance Criteria are used to determine if the completed user story meets the team’s “Definition of Done”. A story isn’t complete without them. Acceptance criteria should be specific to what’s being implemented, and speak to the customer experience and value proposition. They should include system integration expectations where applicable, and negative use case handling. Well defined acceptance criteria ensure quality both by driving good testing, and by enabling accurate story sizing.

   When QA is involved in grooming,

   

   • Make acceptance criteria more clearer:

     Sometimes a ticket will only have a title and a very brief summary. The QA, during grooming meetings should think and revolve around that title to make the acceptance criteria more clearer.

   • Gather missing information:

     Sometimes while reviewing the user story, the QA will think in a different direction and find some required info or test data is missing. By doing this the product managers will get time to add the additional details while the development is going on. So all the missing info can be collected until the ticket is ready to test, which will speed up testing and launch.

   • Bridge any gap:

     1
     QAs are generally good at understanding the business requirements from the end user's perspective. During grooming, QAs should think about the expected behavior of any functionality from the user's perspective, gather the required information and make the feature more user friendly, that results in identifying any gaps in the implementation which in turn save testing and bug fixing cycles.
     

     1.2 Effort Estimation

   You must have heard that

   “A long journey starts with a single step”

   And that single step is the user story. In Agile, efforts for each user story is calculated based on story points.

   “Story Points” are units of measure used in Agile to reflect the amount of work needed to complete a user story. When teams do story sizing, they often forget to include test time in their overall estimation. More often overlooked is the test-fix-retest cycle that’s necessary when a critical defect is found that prevents the story from being accepted. For our sprints to be successful, it’s critical to include these in our sizing. Here’s a guiding principle to ensure the best accuracy in story sizing:

   Story Points = Dev Time + Test Time

   Involving QA in Effort Estimation,

   • Gets a more realistic estimate:

     During each story grooming, when the team thinks only about the happy flow, QA will think beyond the happy path by giving different scenarios/situations and providing relevant information about the flow. This helps the team to provide a more realistic estimate and that in turn helps to weigh in on which features and/or bug fixes can fit in the timeline for each sprint.

2. Involving QA during Sprint Planning:

   

   2.1 Prioritizing

   Sometimes even with great planning, a team can’t meet the original sprint deadline. With the involvement in Sprint Planning QAs get an idea of which tickets are the most – and least – important which helps them to prioritize and concentrate on the most important stories and achieve the sprint goal. QA can target the most complex and time-consuming stories for the early stages of the sprint because both tests and communication around the most complex tasks take longer, so if possible they should be on the top of the sprint priorities.

   2.2 Test Cases and Test Coverage

   Given the face pace of Agile software development, there isn’t always time for QA to write test cases for every story. But when QA is involved in Sprint planning, they will get familiar with all stories in that sprint from the beginning, and utilize initial time to think more about it and write at least some form of test cases which will cover the happy and unhappy user paths and all edge use cases, and identify any pre -requisites or inconsistencies.

   In Sephora, we adopted Shift Left Testing

   2.3 Fixing the critical issues from last sprint

   There may be numerous issues reported by QA during the last sprint. Not all of them have to be fixed within the same sprint schedule. By involving QA, they will pinpoint the defects that need to be fixed on priority and this will help the team to decide which known defects it can commit to fixing during the sprint.

   2.4 Timing

   Remember that the last step in accepting a finished story or defect fix is QA verification. If stories aren’t complete until the end of the sprint, QA won’t have time to do all the verification testing. By involving QA, they can roughly calculate the amount of time needed to complete all the stories in the sprint which will help in picking up the stories for that sprint.

Call to Action

When you’re working within an agile team, finding bugs is a by-product of having a focus on quality throughout every phase in the product life cycle.

The above are only a handful of the many reasons that define the role of QA in Sprint Planning and Grooming. But each reason is significant, even on it’s own – let alone when combined with the rest! Ideally, QA should always play some role in Sprint Planning and Grooming.

Any other thoughts in your mind that a QA should do during Sprint Planning and Grooming?

Did you find some strategies for QAs from this post?

Let me know in the comments.