Get certified - Transform your world of work today


When Should Product Backlog Items Be Deemed Done?

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

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.

Article Rating

Current rating: 4.3 (12 ratings)
Anil Vittal
Well, I will take it with a pinch of salt. Really, we have small timeboxes for sprints so that the team could focus on the limited functionality they take up in their sprint goal. Having PO review the work in the middle will set that goal "in motion" in the small timebox the team has. We should be able to live with any functionality rollbacks we have to do due to some "change in priorities". Correct me if I am wrong.
10/4/2017 12:49:34 AM

Anil Vittal
Well, I will take it with a pinch of salt. Really, we have small timeboxes for sprints so that the team could focus on the limited functionality they take up in their sprint goal. Having PO review the work in the middle will set that goal "in motion" in the small timebox the team has. We should be able to live with any functionality rollbacks we have to do due to some "change in priorities". Correct me if I am wrong.
10/4/2017 12:46:10 AM

Anthony Bedford
I have seen this in practice and the earlier the product owner can review the work the less likely issues occur that cause significant scope creep and work to be not accepted.
9/20/2017 7:16:08 AM

Ken Rubin
Nicely said Martin!
3/14/2017 10:07:57 AM

Martin Smith
Absolutely agree. The review is not acceptance it is an opportunity for discussion. If left to the end then meaningful acceptance is not possible, just like testing at the end is not possible. Also the opportunity during the review is for the Product Owner to "Own" the product in the eyes of the stakeholders and to demonstrate their knowledge of the features and trust in the Team.
3/14/2017 9:03:27 AM

coaching and mentoring
This is actually the kind of information I have been trying to find. Thank you for writing this information.
9/22/2016 12:26:54 PM

your post is very likely thanks
9/17/2016 1:04:44 AM

escritorio de advocacia
Awesome article! I want people to know just how good this information is in your article. It’s interesting. compelling content. Your views are much like my own concerning this subject.
9/10/2016 8:12:37 AM

I am no expert, but I believe you just made an excellent point. You certainly fully understand what you are speaking about, and I can truly get behind that.
9/10/2016 6:16:50 AM

churrascaria orlando
useful information on topics that plenty are interested on for this wonderful post.Admiring the time and effort you put into your b!..
9/9/2016 1:51:11 AM

buy backlinks
I have read your blog it is very helpful for me. I want to say thanks to you. I have bookmark your site for future updates.
8/23/2016 3:06:14 PM

Pandahall Coupons
This was an really great information shared and i will try to make other interact with it.
8/19/2016 5:24:16 AM
was looking for this information and found it only here, thanks!
8/12/2016 9:32:21 AM

Scalp Psoriasis
I am very happy to read this article .. thanks for giving us go through info.Fantastic nice.
8/10/2016 8:15:08 AM

I find it difficult to absorb the information you shared.
8/4/2016 6:54:42 AM
I agree with. This is a very interesting solution. I enjoy reading your blog
8/4/2016 4:19:39 AM

This is a good share. I like your opinion
8/4/2016 4:14:03 AM

This is a great share. I total agree with you
8/4/2016 4:13:08 AM

Dressilyme Coupon Code August 2016
Interesting Blog, I like your opinion.
7/30/2016 6:52:58 AM

Ken Rubin
Glad you like the art. You can download free copies of this picture and many of the other pictures from my Essential Scrum book at:
7/27/2016 9:22:40 AM

Spécialiste référencement
I love this infographic pics from innosolution
7/27/2016 9:05:04 AM

Tonya T'ere Wallace
A product owner should stay engaged throughout sprint execution. Therefore, when the user story is approved by the product owner, the acceptance criteria is considered at this time. In addition, after the development of each story, the story goes through formal testing and the product owner should be approving the scripts and executions. If this is the case, then the review should result in an end to end demo with stakeholders included! #Party!
8/21/2015 5:26:49 PM

Ken Rubin
Hi Gaurav, I agree with everything you said! Let me emphasize your cost-of-delay comment.

Have you ever been to a review meeting where the only people there are members of the Scrum Team (PO, ScrumMaster, and Development Team) and no stakeholders? I have, and I always ask: “Why are we having this meeting?” The typical response is so that the PO has a chance to approve or reject the PBIs. At these meetings I have noticed the PO will often point out some minor issues with an item; issues that could have been easily addressed had the PO pointed them out during sprint execution.

Now the team has to do all kinds of unnecessary work to record and potentially come back and work on the “issues/bugs” in the future. The cost of delay in this situation is growing unnecessarily!
8/19/2015 11:44:52 PM

Ken Rubin
Hi Manoj, good question. Once a sprint starts, unless there is a compelling economic reason, no goal-altering changes should be made during the sprint. So, if feedback from the PO during the sprint leads to a change (expansion) of an item being worked on, one viable alternative to consider is the one you mentioned – create a new PBI that represents the expanded work and insert that new PBI into the product backlog in the correct priority order. Of course, if the economics of working on the expansion are compelling relative to the cost-of-change (e.g., not working on another item we planned to work on), we might do that – but the economics would have to be pretty compelling.
8/19/2015 11:36:18 PM

Ken Rubin
Hi Meetu, sounds like your organization has adopted a model based on PO proxies -- where the BAs are acting as proxies for the actual product owner. In the model you described, when does the actual product owner first get to review a product backlog item?
8/19/2015 11:28:35 PM

Gaurav Dahra
I agree that the review from Product Owner should happen as and when the PBI is ready rather than waiting for the Sprint to end. Doing this will save the time and cost of delay as well because if it happens to see in the Sprint Review meeting for the first time then it would be too late and PBI might not be accepted as completed in case of conflict or DOD not met. There is a slight chance that might be some minor modifications are needed but still the pros outweigh the cons. Also Team would feel more comfortable if this concept of show & tell is adopted rigorously by the scrum team so that PO can give early feedback and thereby helping the time deliver on its commitment.
8/12/2015 4:47:05 AM

Manoj Jain
I agree that regular review from Product Owner during spring execution is needed. What if this review results in a change and the effort to accomplish this can't be accommodated in the current sprint? Shall a new PBI is created and put the in the PB and is prioritized by PO?
8/8/2015 7:12:15 AM

Ken Rubin
Hi Piyush,

I appreciate your comment. I might suggest a slight rewording. I believe that the PO should confirm for himself/herself that the acceptance criteria of the story have been met (instead of the development team confirming it for the PO).

8/6/2015 3:58:43 PM

Ken Rubin
Hi Hrishikesh and Nerida,

Early feedback is certainly the key factor here. It seems wasteful (and arguably negligent) to not get the feedback as soon as practical.
8/6/2015 3:55:15 PM

Manish Soni
Completely agree with the idea as it lends support to the idea of failing fast and adapting to the required changes. Also performing an interim 5th day & 10th day demo of the sprint items for 15 mins during standup, helps present the item to the PO to elicit feedback prior to the Sprint review meeting.
8/5/2015 10:25:47 PM

Meetu Singh
I totally agree to this concept of early feedback. We are practicing it during our sprint where a BA (business Analyst) part of scrum team reviews the stories during development to check if it is matching as per acceptance criteria. BAs as part of our scrum teams are representatives of product owners (Customer representatives) and interact with customer to clarify on requirements. Current scrum team composition includes Developers, Testers (Manual & Automation), BAs and scrum master. The objective of BAs in scrum team is to focus on story grooming along with product owners and facilitate the development & testing.
7/28/2015 7:44:42 AM

Namitha Naveen
That's true, PO responsibility should not be limited to clarifying SBI for that specific sprint in the sprint planning, it must be extended during sprint execution as well, which would definitely make sense for just in time reviews and feedback.
7/28/2015 4:45:48 AM

Piyush Dhangar
Agree with the concept of early feedback, it need not be a demo but a confirmation from the development team to product owner on the AC being met.
7/28/2015 12:53:17 AM

Nerida Carr
I agree as well. I'm fairly new to agile and assumed that would be the case anyway. The risk of identifying problems too late impacts on the benefits of agile delivery.
7/27/2015 1:17:09 AM

Hrishikesh Karekar
I would agree with you. In the spirit of early feedback, the more appropriate time is to review during sprint execution and not wait until the end.
7/13/2015 1:06:13 PM

To leave a comment, please login with your credentials.


Newsletter Sign-Up