Graham Reed

Keep it lean. This does not need to be hours and hours of meeting particularly for cross-business stakeholders. Provide a format for questions, queries and issues to raise, and keep on track. Spot conversations going down rabbit holes and pull back (discuss another time). Where deeper information sharing or conversation is needed, schedule this for a specific session with a specific focus. Show as much as possible using either live (testing) platforms or pre prepared video recordings - users must see the news features in action. Be honest with known issues that are going forward (to release) and list known risks to this.

If done right, this is your first or second review stop of the enhancements made within the sprint, to ensure value and requirements are indeed being met. Ideally, product managers would review this first, of course. But this now is opened up to non-technical stakeholders with their perspectives and insight, and an opportunity to feed back at this stage before going onwards to release. This significantly enhances the quality of anything going out the door by catching misconceptions early. Often this will not pick up bugs during this review, that is a QA thing, but it can pick up business logic type issues and misunderstandings.

The sprint review is a collaborative review of what was produced in the most recent sprint. Typically, this involved both technical teams and key stakeholders within the business, to review what was produced and importantly, is this meeting the original needs (hence having stakeholders in the meeting). It is not a sales demo!

Oh the MVP... how are you still alive! Lets all say it together... minimal VIABLE product. Your MVP has to, in the smallest way possible, provide a solution to the problem the user is having. Anything less than that and you will not please the user, they will not feel you have solved anything and you will not get valid feedback. A login screen must have certain things to be valid, you could not present a screen with just a password entry field and call it 'enough'. I doesn't need bells and whistles, it doesn't need to be perfect, it doesn't need to be pretty, but it needs to solve the problem. And in modern tech, it should still look professional, not slap-dash!

What is the problem, and for who? Do the end users even realise the problem to be solved? How many users in a segment are you looking to help? What value will solving this problem (before even getting to the solution stage) give to your users, and what value will this bring to your business? Understand the problem and understand the users with the problem as full as possible as part of answering the questions above.

Have a hypothesis and test it. What do you think the outcome of mashing these two data items together will be... then test it. Does the data agree... great. Does it disprove, or does it show no pattern at all... also great.