Five topics to consider during sprint planning

During sprint planning, it’s easy to consider the user stories added to the sprint, but that’s not all you have to do regarding test during a sprint. Therefore, I’ll add five user stories that always need to be considered and plan for those as well.

The five topics are:

• Whole-delivery testing
• Regression testing
• Non-functional testing
• Testing due to changes in an adjoining system
• Testing together with other teams

You could name the topics in another way and it may be that you need more. Just change it to suit your needs.

Whole-delivery testing

In every sprint, we have several user stories that must be tested. Each one of them can be seen as an island. To be sure that our delivery meets the needs, we must traverse the ocean while visiting the different islands.

You can also see each user story as an activity in a larger process. We need to make sure the whole process works. (Of course, you can’t make sure anything works. You try to find all ways that it doesn’t.)

Under the whole-delivery user story, we’ll add all tests that cover more than one user story. There is usually a lot of tests.

Regression testing

There isn’t time to do all regression tests you want to during a sprint and often you have some automated regression tests that run after each build. Anyway, we look at the user stories included in the sprint and discuss what already existing functionality could be affected by these changes. Of these suggestions, we choose the critical ones not covered by an automated test case.

Non-functional testing

Some include the non-functional testing in the “whole-delivery testing” as well. I usually handle it separately because of two reasons:

1. I find that it’s easy to overlook the non-functional testing then looking at the whole-delivery testing. Therefore, I find it beneficial to focus just on the non-functional aspects.
2. There are often other competencies needed to perform the non-functional testing. Therefore, I find it easier to handle them under a different user story.

I usually use a list of non-functional characteristics, for instance from ISO25010:

• Performance
• Compatibility
• Usability
• Reliability
• Security
• Maintainability
• Portability

We discuss each characteristic and what tests need to be done because of the changes in the system. For instance, if we’re changing a part of the system that handles high load or introducing the possibility of a higher load, we add specific performance test cases to our sprint. Of course, it can be hard to determine what changes need to be done because of our user stories. This means that we sometimes add more tests during the sprint that we didn’t realize during the sprint planning.

Testing due to changes in an adjoining system

Most systems today have a lot of system dependencies. This means that if we make changes to our system that will influence those depending on us, we need to inform them. It also means that we need to assess each change to an adjoining system and determine what tests we need to do due to those changes.

Testing together with other teams

With all the system dependencies, there is a lot of testing that needs to be done together with other teams. This can be end-to-end testing, integration testing, performance testing, confirmation testing (i.e. testing to see if a specific problem has been corrected) and more. Often, we have discussed with the other teams what tests need to be done before the sprint planning and those form the basis. But there are often some aspects of the user stories included in the sprint that we’re not aware of before the sprint planning. Therefore, we often add new test cases during sprint planning and discuss them with the other teams afterward.

The five topics that I use during sprint planning are of course just examples. You may need other topics or want to divide them differently. All teams I’ve worked with have needed more than just the user stories included in the sprint. Don’t miss those test cases during the sprint planning.