Rethinking the Tester's Role in Sprint Planning

Why Might The Testers Be Excluded From Sprint Planning

The idea looks a little crazy - why would any team leave their testers out of the sprint planning. Yet it happens often enough that many testers spend the sprint working to a plan they never watched being made.

But what might be some logical reasons for a team to exclude the testers?

1- Team is too big

The Scrum Guide describes a Scrum Team as typically 10 or fewer people, and SAFe sizes an Agile Release Train at 50 to 125 people, yet larger organizations often run past both numbers. The fundamental principle of agile methodologies grants everyone a voice in the team, but in larger teams, encouraging extensive participation can become time-consuming. In such cases, testers may be overlooked due to a lack of appreciation for the value they bring or misunderstandings about their contributions.

2- Testers are busy

Agile methodologies are designed not to run separate build and test cycles. But sometimes the intentions are nobler than the reality.

The sprint planning tends to happen at the end of the sprint or the beginning of the following sprint. Sometimes it may happen that the testers found an issue late in the sprint and are working with the developers to fix & retest.

The team has a choice to make - either delay the sprint, or leave out the testers (& maybe even the developer) out of the planning.

Opting to exclude testers from the planning process is the simpler choice, and it is often the path chosen due to its ease. However, the easy route is not always the most effective or sustainable one.

3- Scrum master / Product Owner cannot see the value

In some cases, testing contributions may be undervalued or overlooked by other team members, leading to testers being excluded from planning discussions. This can stem from a lack of awareness about the strategic role of testing in shaping product quality and user experience.

Moreover, specific organizational cultures may perpetuate hierarchical or siloed structures that diminish the active participation of testers in cross-functional collaboration, including the pivotal phase of sprint planning. This organizational dynamic can further contribute to the undervaluation of testing and hinder the holistic integration of testing expertise into the planning process.

Why Involve Testers Early - from an Emotional Perspective

We'll get to the logical reasons later. Testers & the rest of the team are human beings and operate as emotional beings first.

1- Testers speak the truth

The excited Product Owner shares his idea of a fancy feature as they introduce it in the backlog. The business analyst and the developer seem to have absorbed the interest and get to work and start breaking down the feature into stories and tasks. Granted, some analysts and developers ask about the business value, but it is not necessarily in their DNA to always validate what the PO says.

Enter testers - the ones who are born with the pessimistic set of genes - they question everything (which is also one of the reasons why they are sometimes not included in the conversations).

"How many times do we expect this feature to be used by our customers? "What about the feature we build last PI, doesn't it cater to the same use case?"

"The idea sounds really interesting, but testing it might be a nightmare - we should account for it when estimating the true cost of delivery"

These are voices the team needs to hear during the sprint planning.

Testers are also great Risk Managers by default. They can anticipate the risks, and might be able to suggest some mitigations before they turn into real issues.

I wouldn't suggest the other roles in the team wouldn't be honest and upfront, but I know that testers almost always speak their mind - especially when things don't look great.

2- Testers can help you turn the dream into a reality

Testers are designed to see problems. They are also designed to offer solutions.

"The feature is complex, it is going to be hard to test in this sprint. But if we break it down into a few smaller sub-features, then we might be able to secure decent quality in the next sprint."

"The full set of functionalities may not be possible to be finished this sprint. However, we can focus on the top three in this sprint and deliver an MVP version this sprint, and cover the rest in the following sprint."

Testers may not agree with everything the product owner or the scrum master has to say. But it comes from a place of protecting the team and not for the sake of saying no.

3- Testers are part of your team

Scrum teams have many key roles - Product Owner, Scrum Master, and rest of the team. The rest of the team may be engineers of different kinds - developers, analysts, testers, designers and so on. But they are ALL part of the team.

Excluding testers, or any set of roles from the sprint planning is like leaving the salt and oil out of your kitchen cabinet. You may still be able to cook something, but they will not be the same.

It also sends a strong message to the ones left out - Your opinions don't matter, your expertise doesn't count.

Excluding a set of professionals in something as important as sprint planning almost guarantees a dysfunctional team. Missed information easily might lead to mis-information, lack of trust and spiral into something worse quickly.

Why Involve Testers Early - Logical Perspective

Time is money. Ask your sponsor how much the 'time' of your team costs - they'll give you an exact number.

Time is money: Ask your business owner the cost of delay. Ask them how much it costs in time/money/lost opportunity/reputation. Sticking to delivering value on time (aka - delivering the software feature on time) is much more important than the actual dollar value associated with building it.

What is more expensive than a delayed delivery of a feature? Doing it again!

Testers protect the team from rework. And rework can cost the team money, time and reputation.

The arithmetic got harder once AI coding assistants entered the sprint. More code now reaches review inside the same two weeks, and much of it arrives with generated tests attached. Someone has to decide which of those tests check real behavior and which only restate the implementation. A tester in the planning room prices that review work into the estimate. Without a tester, the work surfaces in the last two days of the sprint, which is when teams start cutting scope or cutting corners.

2- Improving user experience

Testers play a crucial role as the initial safeguard for customer interests. They are uniquely trained to consider the customers' perspectives in using the solution, surpassing other roles in the software engineering process. Including testers in sprint planning is equivalent to infusing customer-centricity into the overall process. While good teams focus on the product or service they develop, great teams go a step further by contemplating how the customer would interact with and utilize the product. Testers help your team build around customer centricity.

3- Accelerating Time-to-Market

Testers contribute to building optionality within the team by assisting in breaking down large features into smaller, customer-benefiting MVP increments. Additionally, they play a crucial role in keeping the team on track by proactively addressing risks and collaborating with the scrum master and other influencers in the organization to mitigate them. This proactive approach aids in avoiding rework, ultimately speeding up the delivery of products and services to the customer. Collectively, these contributions enhance overall efficiency and accelerate the delivery process.

Practical Strategies for Including Testers in Sprint Planning

Here are some practical strategies to effectively include testers in sprint planning:

1. Make a commitment to quality

Your customers love high-quality products & services. Testers help you achieve that.

If your company makes a commitment to delivering high-quality products, then It is a no-brainer that your testers get an important role in all the phases of the process.

Cultivate a culture within the organization that values and prioritizes quality assurance, ensuring that testers are recognized and empowered as key contributors to product excellence.

If capacity is an issue, address that core issue and avoid short-cuts like excluding testers (or any other roles) in sessions that shape the backlog.

One capacity problem rarely gets named in planning: the health of the existing test suite. Flaky and slow tests eat sprint time quietly, because engineers rerun pipelines, reopen the same failures, and stop trusting a red build. The tester is usually the only person who can put a time cost on that drag. Raise it during planning and the team can book a story to fix it. Leave it out and the team pays for it anyway, out of the capacity it thought it had.

2. Establish Clear Roles and Responsibilities

Good teams have individuals who understand their job well, great teams have individuals who understand the jobs of other people in the team.

To build a truly high-functioning team, you'll need to establish clear roles and responsibilities for every member of the team. Some practical tips on how to do this are below.

Explain what the testers are supposed to do in the sprint planning - for example, you could set expectations that they are expected to pre-read the stories (or discuss with the analysts/POs) and come up with specific feedback on

• Testability of the story
• Estimates of running the tests
• Risks/dependencies

When testers (or anyone else for that matter) know what is expected of them, they tend to prepare and perform better.

3. Provide Feedback

Some teams may have tried including the testers in the sprint planning only to observe that it did not materially change anything in the outcome. When that happens more often, it is natural that the Scrum Master/Product Owner decides to leave out the testers - and sometimes even the testers themselves may be convinced of it.

It is an easy decision to leave the testers out, but not a good one.

Provide feedback to the testers specifically on what didn't go well, and reiterate the expectations. It is sometimes possible to have underperforming testers who may make it difficult for all the testers. But as a stakeholder it is important to distinguish between the two.

A good solution might be to transfer out the underperforming testers rather than leave the entire testers out of the planning process.