c2ea8f5b-3336-4f3e-b43c-056cf1c7576e

[giscus[bot]]

c2ea8f5b-3336-4f3e-b43c-056cf1c7576e

Do you make sure Sprint Reviews are "tick and flick"? Ensure efficient Sprint Reviews with better communication between developers and Product Owners.

https://www.ssw.com.au/rules/tick-and-flick

[jeoffreyfischer]

Ensure to get everyone in the team involved, to prevent some people from staying silent for the whole meeting

[TobyChurches]

Sprint review emails can contain ALOT of information. Not all of it is worth the screen time, and is more appropriate for relevant stakeholders to review the email rather then spend everyone else time digesting the information. I like to skim through parts of the content when discussing the sprint outcomes (spend time on the bits that count)

[joshbermanssw]

Speed it up - Cut the chit chat for after (i.e taking it offline)

[RobJT-wq]

I don't normally participate in Sprint Reviews but the best tip will always be showing a done video to the product owner before the sprint review so everyone can quickly go through the Sprint Review.

[suiyangqiu]

I like to think of Sprint Reviews as a bit of Murphy's Law in play, what can go wrong will go wrong - demo's always seem to flare up during Sprint Review meetings - so if its something to show off, I think it's always better to go off of screenshots/prepared images, or recorded videos

[0xharkirat]

The best tip is to at least show the done work once to the PO before Sprint Review

[vladislav-kir]

It is important to keep the team informed of your progress through the sprint to keep Sprint Reviews shorter.

[bahjatalaadelssw]

Best advice, don't make it boring. If people have a vested interest they'll ask questions.

[larrycarland]

Great tips!

[ZenoWang1999]

Prepare what you're going to demo ahead of the Sprint Review, and try not to bring too many detailed technical discussions into it. Those are better sorted out separately.

[Berber-Mama]

I like having time to look at the work before a review, so I can bring questions instead of trying to think of them on the spot.

[thom-wang]

One important thing is to stay focused on the current PBI and not use the Sprint Review meeting to persuade the PO/make a decision. That would make the meeting long and tedious.

[debdavid]

My key takeaway was that an effective Sprint Review should be a confirmation of work already demonstrated and discussed with the Product Owner with feedback loops, rather than the first opportunity for feedback.

I'm particularly interested in how we can apply this consistently to data and backend PBIs, where the value delivered may not always be immediately visible in the UI.