Accepting the sprint in the Review meeting? And some other Review questions

Question

My company has implemented a new process of having the team be responsible for the Definition of Done inside of the sprint.

In the Sprint Review meeting the PO is shown the work for the first time and they go through each issue in front of the team and then make comments on the issue e.g. "does it work as intended. if not, how? Defect created..."

Reading lots about Scrum this doesn't seem to be the "Scrum" was to do things, in fact a lot of resources explicitly say that having the review meeting as an acceptance meeting is a bad thing and it should be about feedback.

The problem with this is when should the PO be seeing the work? When do we accept/reject a sprint?

We currently don't have the PO testing in a sprint because of a few reasons:

• If a PO is testing during a sprint then the ownership of making sure issues are understood isn't on the team, they could half understand and just implement something and then get an explanation from the PO after they've showed it to them.
• There's also less need for a team to test their own work because they've got the PO there to catch things.
• The PO has a lot of things to do during the sprint e.g. Backlog grooming, meeting clients, if we add in testing during the sprint to this then there may be too much to do.

Again these are all assumptions we have made so any thoughts on these would be extremely helpful.

Answer 1

The Sprint Review is an opportunity for the team to demonstrate work that has been done to a wider audience, usually stakeholders. The reason we have this meeting is that not all people interested in the work have the time to review it continually during the sprint. It is often convenient for them to just attend the Sprint Review and give their feedback during the meeting.

I would expect the Product Owner to have seen all the functionality prior to the Sprint Review. In fact, a lot of teams I have worked with the Product Owner is the person who leads the demonstration at the Sprint Review. In effect, they are demonstrating what they have asked to be developed to a wider audience.

The Product Owner is reviewing stories during the sprint. My preferred approach is to have the developer demonstrate the functionality of a story to the Product Owner at the earliest possible opportunity, sometimes even while they are still developing it. The sooner the Product Owner sees the story in action, the sooner they will provide feedback. Early feedback is critical to the team working effectively.

Note that they are reviewing not testing. Although there is no harm in the Product Owner doing some testing if they team and the Product Owner find it valuable.

As you rightly point out, the Product Owner has a lot to do during a sprint. It is up to the whole Scrum Team to discuss how the Product Owner's time is best spent. Personally I would say that reviewing stories during the sprint is a high priority for Product Owners as it delivers efficiency savings.