How a Quality Engineer can contribute in a Sprint Planning

Sprint Planning is the ceremony to start the Sprint. Based on team capacity, a group of stories from backlog are set as “ready for Dev” and last alignments before to start to code are completed. Now, team knows what feature and stories will be developed.

This is the moment for the Quality Engineer shows to developer team, all test scenarios created for each sprint stories on Grooming Session. Remember, on Grooming Session, team had the first moment with stories and test scenarios started to be created. Now, you as a Quality Engineer presents the strategy defined to validate these stories and developer team provide you a feedback if these scenarios make sense. After this agreement, team is ready to go.

· Why: Show Test Scenarios for developer team, to eliminate doubts/questions about How to test stories and acceptance criteria. This process will help developers to create Unit Tests and quality Engineer to create functional Automated Scripts. As a Quality Engineer you should be clear in this moment, because when sprint starts, team should have all support need to complete sprint stories tasks.

· Who: Quality Engineer/SDET/Tester.

· When: Sprint Planning.

· How: Quality Engineer shows each positive and negative scenario for developer team. He or She shows de data and access needs to validate stories acceptance criteria. Ask developers if they understood the scenarios.

· Result of this Phase

· Team understanding about how to test each sprint story

· Test scenarios completed to help on Unit testing and Functional Testing

After this ceremony, team will start the Sprint. As you know, all stories from Sprint have a sizing, and a short miss understand could faild the Sprint. So, enjoy this ceremony and double check if team have a clear understand about how to test. Concluding, I like to remenber Rober C. Martin idea’s in this ceremony : “Tests are as important… as the production code is. Perhaps they are even more important, because tests preserve and enhance the flexibility, maintainability, and reusability of the production code.” Clean Code Book