The concept of user stories (or product backlog items) being accepted by the Product Owner before they can be considered “Done” is deeply ingrained in many teams’ understanding of Scrum. Some assume that it is something you just do. Others include it as an explicit statement in the Definition of Done.
But there is nothing in the Scrum Guide about the Product Owner accepting backlog items. In Scrum, an item is “Done” when it meets the Definition of Done. That’s it.
Obviously, that does not necessarily preclude you from having a “The backlog item was accepted by the Product Owner” statement in the DoD.
However, does this practice actually make sense?
Consider the following: So the Product Owner introduces a backlog item that changes the color of the menu bar from blue to green. You finish that backlog item, and then you have to ask the Product Owner: “Hey, have a look. Is this green?”
And yes, that oversimplifies the issue a bit, but essentially that is what you are asking the Product Owner when you ask for acceptance. I am not saying that the Product Owner should not see the result or that they should only see it in the Sprint Review. After all, the Scrum Guide quite clearly states that the Scrum Team (not just the Developers) presents their results to stakeholders. This implies that the Product Owner has seen these results before the Sprint Review. But what was the purpose of showing the Product Owner the finished work?
- Option 1: The Product Owner gets to check if the Developers implemented the backlog item correctly. But isn‘t that the responsibility of the Developers? They do reviews, they run various tests. Do we really have to turn the Product Owner into a test engineer? A lot of Product Owners complain about being too busy. Perhaps one reason is that they do double duty as a member of the Development team, because that’s essentially what they do when they act as a test engineer. And frankly, that’s hardly the core competency I expect from a Product Owner.
- Option 2: The Product Owner clarifies the requirements. So they said in the acceptance criteria that the menu bar should be green. So now they say: “But not THAT shade of green.” Well, if the particular shade of green is crucial, why wasn’t it mentioned in the acceptance criteria? And how often does the Product Owner get to clarify the requirements during a sprint? How do you actually estimate the size of a backlog item if it’s going to turn into a moving target of constant requirement clarifications during the sprint? No, that’s not how Scrum works. The backlog item was refined, it was considered ready, so now you should not renegotiate it. Many teams wonder: “Should we get acceptance from the Product Owner before or after we ran all the tests?” Because you don’t want to present a potentially buggy item, but you also don’t want to waste time on testing an item that the Product Owner will not accept. Both options are wrong, and that dilemma only exists because the team assumes that Product Owner acceptance is necessary.
- Option 3: The Product Owner learns something new from seeing the finished work item. So the Product Owner sees the green menu bar and realizes that another shade of green would have been better. Or purple. Or blue after all. So we have learned something. That is great, because that is exactly why we work in iterations and increments. And what is the unit of an increment in that context? It is a product backlog item. And what is the iteration? It is a sprint. So if we learn something, we place it into a new backlog item for the next sprint (unless we still have room to get it done in the current sprint). So yes, the Product Owner can feed the new learnings back into the team – by creating a new product backlog item – rather than changing (or “clarifying”) an existing one.
So in my opinion, having the Product Owner accept product backlog items to consider them “Done” is not just unnecessary. It also contradicts the principle of working in increments and iterations, which is a core concept of agile methodologies.
AgileEvangelist 