Engaging Stakeholders Without Derailing the Team: A Scrum Field Checklist

One of the tensions in Scrum is between stakeholder engagement and Sprint stability. Stakeholders need visibility into progress, the opportunity to provide feedback, and confidence that their requirements are being addressed. The team needs a stable Sprint Goal and protection from unplanned interruptions. Managing this tension well is one of the most important responsibilities of a Product Owner and a Scrum Master. Here is a checklist for doing it effectively.

Before the Sprint: Checklist for Setting Expectations

1. Communicate the Sprint Goal and the Sprint Review invitation. At Sprint start, communicate the Sprint Goal to all stakeholders and confirm the Sprint Review time. Stakeholders who know when and how they will get visibility are less likely to create ad hoc requests for updates.

2. Establish a communication norm for urgent requests. Agree with stakeholders on how genuinely urgent requests should be raised during a Sprint. The answer should involve the Product Owner (not direct contact with the development team), and should include a definition of "urgent."

3. Confirm backlog transparency. Make sure stakeholders can see the Product Backlog and understand what is coming in future Sprints. Stakeholders who have visibility into the backlog are less anxious about whether their priorities are being addressed.

During the Sprint: Checklist for Managing Contact

• Route all stakeholder requests through the Product Owner. The development team should not be directly taking requirements changes or priority requests from stakeholders during a Sprint. Every such request should go to the Product Owner, who decides whether to address it now or add it to the backlog.

• Distinguish between feedback on current work and new requirements. A stakeholder who says 'the feature we are building is heading in the wrong direction' is providing feedback that may affect the Sprint Goal. A stakeholder who says 'I have a new requirement' is making a backlog request. These require different responses.

• Hold a mid-Sprint stakeholder communication if the Sprint is longer than two weeks. A brief written update -- Sprint Goal status, key decisions made, any risks -- reduces the information vacuum that leads to stakeholder anxiety and ad hoc enquiries.

At Sprint Review: Checklist for Productive Engagement

• Prepare the demo before the Sprint Review, not during it. A Sprint Review where the team is setting up the demo environment at the start of the meeting is not ready.

• Frame the Sprint Review as an inspection of the Increment, not a presentation of effort. Stakeholders are not there to hear what the team worked on -- they are there to see what was built and provide feedback on whether it meets their needs.

• Capture all feedback from the Sprint Review explicitly. Items that emerge from Sprint Review feedback should be captured as potential backlog items, reviewed by the Product Owner, and prioritised in the next Sprint Planning. Feedback that is not captured is feedback that will create frustration when it is forgotten.

XNM supports public-sector organisations in building effective Scrum team practices, including stakeholder engagement and Product Owner coaching. Reach out to XNM's program & project delivery advisory team to discuss stakeholder engagement and agile delivery for your organisation.