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

This is a very common problem. The short, direct answer is that the Sprint Review should not be the first time that the PO sees the completed stories. The PO should review stories as soon as they are done in the sprint. This will free up the Sprint Review to focus on feedback.

There are three other points in your question that are worth addressing.

1) If the PO is "testing" the story, they may be taking on too much of the work.

While the PO will certainly review and try out the new functionality, ownership of technical quality still belongs to the team. If acceptance criteria read:

User should be able to change their address

Then I'd expect the PO to change the address, but not try special characters, negative cases, SQL injection, etc. The team should be confident that their work is completed and meets quality expectations when they ask the PO to sign off on it. This should hopefully make asking the PO to review stories in the sprint much more practical for your team.

2) The PO should be engaged with the team throughout the sprint.

It's ok for a team to mostly understand the ask of a user story and check in with the PO as they progress. In fact, it will almost certainly happen anyway. Sometimes you aren't sure what questions you need to ask until you start coding and run into a problem, so instead of trying to avoid this scenario, we should instead make sure that clearing up questions between the team and PO is easy and smooth.

Now, your concern is not unfounded. It is possible to abuse this dynamic and the PO should call it out if he thinks that is happening, but a healthy amount of back-and-forth is expected.

3) Are your stakeholders joining you for the Sprint Review?

It may just be the way you described it, but it sounds like your Sprint Review is really just between the development team and the PO. It should really be about the whole Scrum Team (PO, SM, and Dev Team) presenting the work to stakeholders and gathering feedback from them.

Answer 2

In fact, there's no such concept of accepting/rejecting a Sprint in Scrum. A Sprint can, under specific circumstances, cancelled before it's over, but nobody can reject a sprint. Also a sprint is pretty much always composed by work that is done and work that is not done, and this is not up to the judgement of a single person. That's why a DoD is there: to ensure that the vision about what is expected is clear and shared among the team.

The review is thus intended to take stock of the situation, inspect the work done, and see how this impact the work still to be done.

Here's what the guide says about that:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

That said, and if needed, the PO should be able to see and test potential increment as soon as it is done, and in the most transparent way.

Answer 3

There is no such thing as "accepting the Sprint". If you are Done with no further work required to ship to production then your code is committed and tested. Its in the product.

The only purpose then of the sprint review is to provide feedback.

The PO should be working with the team during the sprint and be intimately familiar with what was Done and the choices that were made to get to Done.

Refer to: http://scrumguides.org

Answer 4

TL;DR

Acceptance testing is not part of the Sprint Review. It should be part of your Definition of Done, and integrated within the Sprint itself.

Clarifying the Product Owner Role and the Sprint Review Ceremony

There are some other great answers here already, but I think there needs to be a tighter focus on how acceptance testing fits into the Scrum framework. To do so, it is worth noting a few key points:

1. The Product Owner (PO) never "rejects" a Sprint, or even user stories. The role of the Product Owner is to manage priorities on the Product Backlog, to help define the Sprint Goal, and to terminate the Sprint early if the Sprint Goal cannot be met.
2. Stories are either "done" or "not done," which is why the team must have a "Definition of Done" that is agreed upon by the entire team including the PO.
3. The Sprint Goal has either been met, or it has not.
4. The purpose of the Sprint Review is to "inspect the increment" of iterative development. The Product Owner can then adapt the Product Backlog based on what was done or not-done, and incoporate feedback from the stakeholders.

What seems to be missing from your current process is inclusion of formal acceptance tests as part of your Definition of Done. Acceptance testing should be an integral part of the Sprint itself, rather than something done after the fact or by hijacking a Scrum ceremony with a completely different purpose like the Sprint Review.