You’re welcome Javed. The sprint review meeting provides a good opportunity to determine what is done and how much progress has been achieved–as well as to collect feedback from (selected) users and customers and the stakeholders. The product owner may review backlog items just in time as they get done in the sprint if this works for the Scrum team. The development team should demo only items that the members believe to be done. Hope this helps!

Many thanks for coming back Roman. The only clarification I’m looking for is it good practice to hold the sprint review and use that forum to move stories to done. My experience tells me to use DoD and ACs to close stories and then demo what has been completed in the sprint review; not to use it as a forum to close stories and only end the sprint after the sprint review meeting.

Thanks for sharing your question Javed. In Scrum, the product owner determines if an item is done using the definition of done and, if user stories are used, the stories’ acceptance criteria. If other Scrum team members repeatedly disagree with the product owner, then investigate in the next retrospective why this is. Is the definition of done not clear? Is it too weak or too ambitious? Or is the role of the product owner not properly understood? Your Scrum Master should be able to help you with this issue. Good luck!

Thanks for sharing your question, Manisha. How important it is to immediately validate a product increment and the related product decisions, depends on the amount of innovation and uncertainty present. When you build a brand-new product or create a major update of an existing one, having a lag between finishing the product increment and receiving feedback/validation is undesirable, at least in the first few sprints of the development effort, as this might result in the dev team heading down a wrong path. But once you have addressed the major risks in your product backlog, such a delay is usually not a big issue. (I discuss different options to gather feedback and update the backlog in the article “When Should Product Backlog Grooming Take Place“.)

Having said that, I would be interested to understand what it would take to have the stakeholder feedback in the sprint review meeting. It would be helpful for the dev team members to witness the stakeholders’ reaction to the new increment and directly hear their feedback. Additionally, don’t forget to regularly collect user feedback and data. The users of your product ultimately determine its success, not the stakeholders.

Hope this helps!

Question: What the team is doing – demo to PO and then 4 days later demo to other stakeholders while the Scrum team is on its second sprint – is this a good practice and should it continue? And how does one account for the lag in documenting the user stories.