Accepting the sprint in the Review meeting? And some other Review questions
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.
> The problem with this is when should the PO be seeing the work?
The PO should have a view of the work throughout the Sprint, as this is the best way to control delivery risk in a timely manner.
> When do we accept/reject a sprint?
A Sprint is a time-box which occurs and then expires, it is not something to be accepted or rejected. An increment must be delivered by the end of the Sprint which is of release quality. The decision whether or not to release that increment is a matter for the Product Owner.
The Scrum guide establishes a framework, but I think it's up to you to build on top of that framework to do what suits your needs.
The Scrum Guide states that in the Sprint Review: "The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”".
The Scrum also tells you that PO should not participate in the daily stand ups, but they are welcome to attend and just listen if needed. This is so that the team can stay self-organized and focused on what they had planned in the Sprint Planning. However, PO should be available to clarify things if the team needs him/her, or if the team needs to negotiate the scope of the sprint due to some risk.
Therefore, the Sprint Review is really where you get a full feedback on the work done in that sprint, and the work can be accepted or rejected based on the Acceptance Criteria of the User Story. The PO should call the stories Done or not Done depending on the result of the sprint presented in the sprint review. This is different from Acceptance Testing, which should be the result of a UAT rollout to the end users or UAT users, independent of Development's team current sprint.
In other words, first PO comes to accept that the stories indeed meet his/her acceptance criteria as set with the development team, and decides whether or not he wants to release an increment. The UAT is done by the USERS not the PO. A story may meet all of PO's acceptance criteria and the DoD, but the feature might have been designed with a poor understanding of the user's requirements (maybe PO didn't fully understand these requirements himself/herself) and therefore not pass UAT. in that case, PO may consider a new PBI to be discussed in planning later.
Also, this interactive lesson might help you: http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting…
> The Scrum Guide states that in the Sprint Review:
> "The Product Owner explains what Product Backlog
> items have been “Done” and what has not been “Done”".
Here we see an example of how the term "Done" can be applied in different contexts, and why the Guide advises us to be clear about how we use it.
The Product Owner should have clear sight of whether or not the items on his or her Product Backlog are "Done". In the case of user stories this may be asserted (at least in part) by acceptance criteria. However, the PO does not necessarily have clear sight of whether or not the increment being provided meets the Definition of Done, since that can assert technical qualities of interest to the Development Team.
The Scrum Guide states that in the Sprint Review: "The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”".
To who does the PO explains that ? For me it is not to the Dev Team but to the stakeholders.
The Dev Team knows allready what is or is not "Done".
So if the PO explains to the stakeholder, he certainly should have this information before the Review.
Posted By Olivier Ledru on 26 Feb 2016 12:40 PM
The Scrum Guide states that in the Sprint Review: "The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”".
To who does the PO explains that ? For me it is not to the Dev Team but to the stakeholders.
The Dev Team knows allready what is or is not "Done".
So if the PO explains to the stakeholder, he certainly should have this information before the Review.
Yes, definitely. And that is what I also was saying earlier. The DoD should be agreed upon by all members of the Scrum Team (which includes PO) and must be made available to everyone. I personally share this DoD such that anyone even the stakeholders can access it at all times (we use Confluence). As a PO I remind the team about the DoD when declaring storied as Done or not Done because sometimes the team forgets about some criteria that we have agreed. So it's still beneficial to the team as well as stakeholders. For example ، documentation was part of our DoD and the team had missed this for a story they had assumed as Done. I as PO didn't accept the story and reminded them that documentation was part of our DoD...
> To who does the PO explains that ? For me it is not
> to the Dev Team but to the stakeholders.
The Dev
> Team knows allready what is or is not "Done".
We might *hope* that the Dev Team would know that, because the quality of the refined backlog items and the ensuing collaboration should have made it clear. However, even though there are a range of good implementation practices that can help de-risk delivery, Scrum does not prescribe them. Hence it is possible, within the strict letter of Scrum, that the PO may be left to account for "done" and "undone" items at the last minute.
Having said that, I would choose to interpret the words differently...the Product Owner is explaining *back* to the Development Team what work has been done or not done. That's fair enough, and not an unreasonable thing to do in a Review.
I understand and agree with your view Ian, the final word comes from the PO.
The issue I see too often is that the Dev Team works on its side during the Sprint and the PO discovers the increment at the review. For these Dev Team, the review is performed as a "validation" meeting, and not an opportunity to adapt the PBL with the feedback of the stakeholders.
I find it depends on sprint length. 2 week sprints the PO should have no problem leading the review with the team and stakeholders. It also makes sense for the PO to do the demo as it ensures the PO has a reason to focus on the work during the sprint. It's not fun showing up to a review, and having to do a demo with no idea what was built! That only happens once...