In Scrum, the product owner decides whether the development team has successfully completed a product backlog item (PBI) or not. Each PBI should have acceptance criteria associated with it and when the team completes its work, the product owner ensures the acceptance criteria are met. The question is: “When
does the product owner review a PBI to determine if it is done or not?”
I encounter Scrum practitioners who believe the appropriate time for the product owner to make this determination is at the sprint review meeting. I don’t agree. The appropriate time is during sprint execution. See the figure below that illustrates the differing opinions.
You can download a hi-res copy of the Scrum Framework and other images from the
Visual AGILExicon® at Innolution.com
Here is my reasoning. At the sprint review, the team is allowed to present only completed work—work that meets the PBI-specific acceptance criteria and the agreed-upon definition of done. This implies, then, that sometime before the sprint review, someone has determined whether or not each PBI is done; otherwise, how would the Scrum team know which items to present?
As I said, ultimately it is the product owner’s responsibility to determine if the work is done or not. The product owner should be performing just-in-time reviews of product backlog items as they become available during sprint execution. This way, by the time the sprint review happens, the team knows which PBIs are complete.
The competing opinion is that the product owner should review and formally accept the work only during the sprint review. People with this opinion believe that if the product owner is allowed to review the work during the sprint, he might request changes that go beyond clarification—goal-altering changes that will disrupt sprint execution. This is a potential risk, but the benefits of early product owner reviews (fast feedback) far outweigh any downside.
Furthermore, if the product owner sees the team’s work for the first time at the sprint review meeting, he has seen it too late. Here’s why. The product owner must be available during sprint execution to answer questions and clarify PBIs. While fulfilling these obligations, the product owner should also review the ongoing progress the team is making and provide critical, in-flight feedback that can be acted on in a timely, cost-effective manner. Deferring this feedback until the sprint review would create unnecessary work and likely frustrate the team (“Why didn’t you mention that during the sprint, when we could have fixed it easily?”). It also could potentially irritate the stakeholders at the sprint review meeting (“This feature would have been potentially shippable if you had just handled those things during the sprint!”).
Beyond this, however, a product owner who rejects or questions work during the sprint review might not appear to be on the same page as the rest of the Scrum team. That disconnect could come across to the stakeholders as the old, adversarial, us-versus-them problem. The product owner and development team are on the same Scrum team and should come across as one unified team during the sprint review meeting.
Bottom line, the product owner should review PBIs during sprint execution and not wait until the sprint review meeting. See my prior Spotlight blog posting
for a description of the purpose of the sprint review meeting.