The Agile Edge: Rethinking Testers’ Role in Sprint Planning

Your CEO goes on stage announcing a new version of the product. The market is buzzing with great talks about the cool new product.

As a Scrum Master or Product Owner, you feel the excitement – this is what your team has been working on for the last few sprints.

Launch day!

Most of the customers go for the most obvious features, they work great!

And there it is, some customers try the other fancy buttons on the screen. And oops – something seems odd – a production issue! And the issue quickly snowballs – the newsreels capture and..
You know how the rest of it goes.

You’ve seen it many times and as a tester, I know what you are thinking – “If only the tester had their say during the sprint planning”. It seems like a wild connection between a substandard product and sprint planning – but they are inherently connected in ways that may not be obvious.

Why Might The Testers Be Excluded From Sprint Planning

The idea looks a little crazy – why would any team leave their testers out from the sprint planning. But surprisingly, only 61% of testers are involved in sprint planning, especially in smaller organizations (according to a survey by LambdaTest).

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

⁤

1- Team is too big

While the suggested Scrum team size ranges from 9 to 11 individuals, and the Agile Release Train is advised not to exceed 150 members, larger organizations often surpass these limits. 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 (timestamped at the time of this writing in Feb 2024 – who knows what may happen in the future).

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 dis-functional 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 that 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.

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.

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 do this below

Explain what the testers are supposed to do in the sprint planning – for example, you could set expectations that they are expected to 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.

Wrapping Up

Integrating testers into sprint planning isn’t merely a convenience—it’s a strategic necessity. The reason for excluding testers out of the sprint planning meetings may be many, but none of them are overcomeable.

Testers add a lot of value to the sprint planning process – by providing valuable insights that shape the plan, highlighting the risks, helping deliver MVPs etc., But it is up to the Scrum Master/Product owner to get the testers to play their part by setting appropriate expectations and providing the necessary support.

Testers are part of your team. You want them to say YES before releasing a product to your customers. You cannot get the best out of them if you consciously exclude them from a critical meeting of the sprint. A plan becomes a lot more ‘achievable’ when the testers have had their say in shaping it. Your team’s credibility may actually be dependent on it.

Consider using a right software testing solution like LambdaTest that allows users to run manual and automation testing of web and mobile apps across 3000+ browsers, operating systems, and real device combinations.

Over 2 Million users across 130+ countries rely on LambdaTest for their web testing needs. Using LambdaTest, businesses can ensure quicker developer feedback and achieve faster go-to-market.0

Ilam Padmanabhan

Ilam Padmanabhan is a seasoned Tech/Financial services expert with a history of delivering multi-million dollar global projects in various Delivery and QA roles. He frequently authors articles on his personal website where he explores the latest industry trends, cutting-edge technologies, and best practices for thriving in today’s rapidly evolving landscape.

See author's profile