Sprint Review Guidance

This Sprint Review is for our colleagues to be aware of what’s in flight and what’s coming up, giving them the information they need to do their job and support the delivery of the functionality that we’ve been working on.

We should aim for these Sprint Reviews to be valuable to all stakeholders, including senior business stakeholders.

Some suggestions:

• Focus on what will be interesting and valuable to our colleagues
• Inform our attendees of what’s coming up in the Sprint Review and why they’d be interested in attending - put on a sales pitch.
• Talk about value delivered at the feature/functionality scale and progress towards key outcomes, not BLIs completed.
• Communicate the impact on customers and users.
• Make effective use of demos, but do not demo for the sake of it – focus on functionality that our stakeholders, customers, and users might see.
• Communicate anything that colleagues need to do to help deliver this functionality, i.e. BAT expectations, QCP (Quartex Community Platform) updates, customer communications, etc.

• Invite conversation with our colleagues.

• Save department-specific discussions for our Department Sprint Review

• Use Departmental Sprint review to talk about specific BLIs, challenges, tech debt, and dev experience.

• Prepare for and run the review as a team

• Each team should announce (via the meeting chat) what they’re going to talk about in advance, so that colleagues can plan to attend.
• Collaborate as a team, everyone brings their expertise to the presentation.
• Leads and PM support the presenter when there are questions, without discouraging engagement.