How do you include stakeholders in Scrum testing?

Being a little facetious here, but more than the specifics, I'd encourage broad recognition of who are the stakeholders and actually having conversations with then individually and collectively. Cultivate a relationships where you're having a running dialogue not just radio silence other than during the sprint review

a stakeholder is "a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review/Testing

There definitely are benefits to including stakeholders. To do this, there is a need to clearly define the expectations of the testion. Furthermore, it is important to meet with as many stakeholders as possible forst. You need them to not be suprised in the reveal but rather come prepared to contribute. Use the divide and conqour approach. Who are your allys? Make sure they are on board first. They'll make positive contributions if the general testing is going south. And if you can, try and win over those who may prove resistant to your work before the meeting. or at least, soften them.

Involving stakeholders early and more often is a lot more important than including them on a need basis. It gives the project/scrum team a constant perspective/feedback of the product that they are developing. This leads to first time right product delivery. There are events based in scrum which helps out this into practice. Events like sprint planning, sprint review, etc.

During my engagement with one of the scrum teams, we were able to obtain good results by incorporating mid-sprint reviews. During this mid-sprint review development team, used to demo the implementation which were 80% or more incorporated till the point in the sprint. This helped the team to get an early feedback on the implementation and the product owners to understand the current state (exactly) and make further informed decision.

This almost goes without saying, but it bears repeating as it is easier said than done. We (as scrum teams) don't create *for* stakeholders, we create *with* stakeholders. We have no way of knowing that we are on the right track if we don't start by including them, as no matter how well we *think* we know them, the proof is in the pudding so to speak.

Implementing feedback loops and tools foster timely and transparent communication, ensuring that stakeholder input is not just heard but actively integrated into the development cycle. Regular surveys and interactive sessions like focus groups and demos can yield invaluable insights. Moreover, utilizing platforms such as Jira or Slack can centralize issue tracking and resolution, thereby streamlining the iterative process. It's crucial, however, to balance the inflow of feedback to avoid bottlenecks.

Of course. Short feedback loops and transparency are important. Everyone knows that. But Scrum teams, especially in organisations relatively inexperienced in agile/scrum ways of working, are sometimes afraid to be "too open" to stakeholders, no matter how strongly the stakeholders express their wish for honest, fast, clear information about everything. Yellow flags: - "We can't give just EVERYONE blanket read access to our Jira board/SBL/PBL/etc... Right?" - "Let's schedule a private meeting to discuss this hot button issue." - "Instead of just building our ideas and testing it with the stakeholders, let's present the problem to our stakeholders and wait for a decision first."

When it comes to testing, the more interactive, the better. Testing is not "the phase after development," it should start when the team receives requirements. That's when the team starts to define what successful implementation looks like.

Balancing stakeholder feedback with team autonomy is a delicate art in Scrum testing. Prioritization tools like MoSCoW, the Kano model, or a value proposition canvas can be instrumental in aligning feedback with product goals. Empower teams to leverage data and evidence to make agile decisions, ensuring that they are not stifled by excessive input.

This is what I responded as the last yellow flag to the previous point: "- Instead of just building our ideas and testing it with the stakeholders, let's present the problem to our stakeholders and wait for a decision first." Always Be Coding. Create things in collaboration with stakeholders, but avoid *holding back* the creation waiting for feedback or decisions. In general, it's better to have something that needs changing, than to have nothing at all.

Maintaining a delicate equilibrium between stakeholder input and team autonomy is crucial for a dynamic testing process. Recognize that team members possess valuable insights and expertise, allowing them to navigate through feedback and make decisions that align with project objectives. By integrating prioritization techniques, like MoSCoW analysis, you ensure that stakeholder feedback is not only considered but also weighed against project constraints and goals, fostering a balanced and effective testing approach within the Scrum framework.

Ah. The most overlooked part of the three Scrum Master areas of attention, and the reason there is often an unnecessary and hurtful distinction between Scrum Masters and Agile Coaches. Scrum Master serves the team - that's often clear enough, and where it always starts. To serve the product owner however is often already hard enough, as some organisations in transition tend to have the PO be relatively abstract and far away. But to serve the ORGANISATION to adopt agile practices... This is what is typically left to others and/or entirely disregarded ("Agile? Ah, that's the thing that the nerds in IT do, right?")

Involving stakeholders is a delicate balance of education and coaching. Begin by demystifying the testing process. Explain in layman's terms how testing fits into the Agile framework and why their input is invaluable. This transforms ambiguity into clarity, fostering stakeholder engagement. Next, coach them on how to provide effective feedback. This isn't about what's wrong, but also what works and why. Encourage them to think from the end-user's perspective. Regularly involve them in review meetings and encourage open dialogue. This coaching not only makes them valuable contributors to the testing process but also deepens their understanding of Agile principles, turning them into allies in the pursuit of delivering high-quality products.

As per SAFe, key role of scrum master is coaching the Team. As a servant leader of Agile team, SM has to ensure key stakeholder has to be invited & everyone has to understand their R&R inside and outside Agile Team.

Including stakeholders in Scrum Testing helps us in building Trust, maintaining Transparency and being flexible. Scrum Testing can be made a fun event where everyone would feel included, heard and be a part of the product journey. In order to encourage the stakeholders to be a part, spread awareness of the importance of the Scrum testing through invite, make it more interactable through in person meetings if possible or virtual sessions, conduct small interactive sessions of voting or changes needed and including stakeholders in the retrospective meetings.

"Great ideas can come from anywhere." All ideas, even the ones that are not selected or prioritized, are important to reaching the best solution. So make sure stakeholders all feel valued.

Shift Left is the best way, early engagement helps in cost saving and faster deliveries. More the clarity, lesser are the gaps and better n faster are the deliveries.

Create test scenarios together by bringing the best of both the systems - Integration testing & User testing. Use shift left approach i.e. test often & early. fail fast & improve. Learn from the findings & improve continuously

“Scrum testing”. There’s no such thing. There’s SOFTWARE or PRODUCT testing, software quality assurance. Dunno why people keeps mixing process with product. Scrum is a guide for some processes. At the time it takes the product’s role in your mind, it begins to be a problem.