Should the Product Owner Accept Stories aka PBI's?
I've been witnessing many teams creating this stage gate kind of approach where Development Team members won't move a Product Backlog Item (user stories) to the Done column on the team board. The rationale is that only the PO can accept a story and move it to that column. In fact this practice has gone even further where the organization has a governance team that audits these actions and advises what % compliant the teams are.
I have not interpreted any part of the Scrum Guide that states the PO has any such responsibility i.e. to Accept Stories and move it to the final column. Should the PO really even do this or just collaborate with the team through the Sprint?
Where I need more clarity is, does the PO have any role in Inspecting each PBI (story) or the Increment before the Sprint Review?
Where did this concept of the PO has to accept the story come from?
I'm not sure where this concept came from, but it probably comes from the idea that the Product Owner is the representative of the stakeholders on the Scrum Team and is most closely aware of their needs and desires. The Product Owner is responsible for ensuring that the Development Team understands the Product Backlog Items, so it seems to follow that they can also check work that the team believes is done to make sure that they understood it properly.
Have the Development Team and the Product Owner talked about their interactions, and codified what "Done" means in the Definition of Done? I can see something like this being useful in some cases, but it can also be a bottleneck depending on the Product Owner's schedule. Some level of involvement with the Product Owner (or any other stakeholder) to look at the work prior to the Sprint Review seems prudent, since it means the Development Team gets earlier feedback.
As far as compliance goes, one of the most important things is to say what you do and then do what you say. If your Definition of Done (or some other aspect of your process documentation) says that your Product Owner reviews the Product Backlog Items completed in a Sprint and is the one who determines if they are done correctly, then that is what is expected. This isn't a rule of Scrum, but a self-imposed rule. If it's not working out, then change the self-imposed rule by updating the Definition of Done and associated process documentation and then doing whatever it is that you say.
I usually see this because there isn't a good understanding of what it means to be complete with a story. The Definition of Done should be applied at the increment level and not the Product Backlog Item (PBI).
The Scrum Guide states:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
The last sentence is where I have found the least area of completeness. While User Stories aren't included in Scrum it has become the defacto standard. Acceptance Criteria was added as part of the User Story makeup to help address this. (It was not part of the User Story originally created with Extreme Programming). But it is usually the worst portion of the definition. So everyone will resort to having someone "sign off" on the item. Some places it is QA, others the Product Owner. This also goes back to the concept of a "single wringable neck" from days of yore. And many companies still subscribe to the need to have an "authority figure" for this kind of decisions.
The Definition of Done should be applied at the increment level and not the Product Backlog Item (PBI).
@Daniel Wilhite, Why can't it be applied at the PBI level? See below from the Scrum Guide.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.
Can't a single PBI can become the Increment? In that case, would it still not apply?
The rationale is that only the PO can accept a story and move it to that column.
Whether a PO accepts a story or not is irrelevant to Done. The ability to achieve Done should lie wholly within the Development Team, and they ought to be trusted to make its satisfaction transparent.
@Steve Matthew In the scenario you presented it is still being applied to the increment and not a story. The fact that a single story created the increment is not really relevant.
Here is my opinion on why it is said to apply at the increment. There can be 1 to many stories that make up the increment. The Definition of Done(DoD) is a common understanding of what needs to be done in order to produce a single potentially releasable increment of value. If each story you do is intended to create a single potentially releasable increment of value you are still applying the DoD to the increment.
Take for example a pretty common element of DoDs. "All work has been merged to master". If you have 4 stories that are going to make up your potentially releaseable increment broken like this:
- Create backend service that will update data elements in the database
- Create a user interface that allows the user to view all of the data in <some set of db tables> on a mobile device
- Create a user interface that allows the user to view and modify the data in <some set of db tables> via a web browser
- Remove all code that supports the current system for managing the data in <some set of db tables>
Given that most companies want master to be the code that is deployed to Production would you merge to master the code produced for #4 immediately upon completion if it was the first item finished and run the risk of some other group pushing master to production before your code is ready? I know there are many ways to work around this but I tried for something simple that would be relevant.
The DoD applies to the entire increment, not individual stories. Again this is my opinion and I encourage others to form their own. And by the way, I currently work for a company that applies a DoD at the story level and every team has their own DoD with no organizational definition in existance. I am not a fan of it but then it is working for the organization and all of the teams so I'm not going to fight it.
Whether a PO accepts a story or not is irrelevant to Done. The ability to achieve Done should lie wholly within the Development Team, and they ought to be trusted to make its satisfaction transparent.
@Ian Mitchell, I agree. I was just curious as to how this practice came into being. Personally, I don't see it being of any value other than another unnecessary hand-off and process.
Does the PO have any role in "accepting" or not accepting a PBI or the Increment before the Sprint Review? During the Sprint Review, the stakeholders should decide if the Increment serves their purpose right?
Does the PO have any role in "accepting" or not accepting a PBI or the Increment before the Sprint Review?
I'd suggest that they ought to collaborate throughout the Sprint, and help ensure that the increment is acceptable. Failure to do this risks the incurral of waste.
On which level is DoD?
DoD is on the increment but as soon as one PBI is done an increment is born
that implies that DoD is applicable on both levels
test descriptions are on the level of the PBI and can be interpreted as a more generic term for acceptance criteria
the scrum guide leaves room for the PO to define the acceptance criteria but also accept the PBI as done.
what does (not) accepting by the PO mean?
i always assumed "accepting that the PBI/increment meets the DoD"
but here I am stuck: how can the PO assess the more technical quality aspects of DoD, the developers would be much better at assessing quality standards.
Each PBI has to meet the DoD. If a PBI does not meet the DoD the Developers cannot class it as done, therefore the PO will not look at it in order to decide if they will accept it or not.
Once the sprints timebox is over, any PBIs that have not met the DoD will be re-evaluated and placed back into the product backlog, for possible selection during a future sprint planning event.
The 2020 version of the Scrum Guide doesn't say anything about the Product Owner accepting an increment. I'd suggest that the imperative in Scrum is to release Done work as soon as it is completed, so empirical feedback can be obtained and depreciation on the investment minimized. A just-in-time, value-based decision not to release Done work might be taken by the team, yet should be exceptional.
My previous statements were based on the 2017 version of the Scrum Guide. But if you read it, you can see that I am in line with the 2020 version as I said that each story could be an increment or it could be a set of stories. The 2017 version had a concept that a Sprint would create a potentially releasable increment of value which could be released to production. The 2020 version does not change that. This statement is from the 2020 version under the section "Scrum Artifacts" (emphasis added by me)
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
For the Product Backlog it is the Product Goal.
For the Sprint Backlog it is the Sprint Goal.
For the Increment it is the Definition of Done.
The biggest difference is that now when a single story meets the Definition of Done an increment is born. But it doesn't say "an increment is born and pushed to production". I still feel that the Definition of Done applies to the increment. If a team decides to apply it to each Sprint Backlog Item, I have no problem with that. But in the end, everything that is pushed to Production has to meet the Definition of Done.
In the 2020 revision of the Scrum Guide the word "accept" is used once and "acceptance" is also used once. Both are in the same paragraph found in the subsection "Adaption" of the section "Scrum Theory".
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
No where in the guide does say anything about a Product Owner accepting, signing off on, or approving. The guide makes it clear that Scrum Team is responsible for creating the increment and that the Definition of Done enables them and people outside the scrum to know what it means to be done.
The Scrum Guide does not seem to strictly forbid PO to accept PBIs, nor does it encourage such behavior. At first glance it seems it may be open to interpretation.
Here's what supports that PO should not accept PBIs:
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint
Also:
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
Now, I'm not sure if the Definition of done could contain a point saying something like "and PO approved it". In my opinion it would go a bit against the spirit of team's empowerment that Scrum is all about. To me, DoD should describe objective criteria independent of an opinion of a single team member, including PO.
Now, what seems to support that PO could be the gate for accepting PBIs:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
This leaves the door open for setting up a PBI approval process with the PO being the gate.
It would be best to search for research on what works better (I haven't checked if such research exists).
I think you guys are derailing the answers on books quote interpretations, which I highly doubt is helping. And thats now answering the author of this topic.
To answer your questions, even if it's not written in the guide .. the guide is ... only a guide : you have to adapt to your RL environnement. The only REAL question is : "Does this way of closing PBI blocks or angers or impedes your team in any way, and prevent them from delivering quality increments ?"
Gather info discretly, but only bring the issue in the Retro if your dev team is not liking it .. if there no concensus, you can give the scrum's and your's interpretation, but otherwise, if the team don't think it's a problem, I wouldn't bring it into focus until I'm 100% sure that there is no 'trust issue' between your team and Management. And that your team is starting to perform well, and this part is one of the 'next step' to go even further.
Because, all in all, I will normally review PBI during the sprint with the PO, to avoid bad surprises during Demo ...
How this came into a rule ?
From experience, during the demo , the stakeholders and the PO will review all the elements which are done, and if a PBI isnt to their liking, they will ask for changes and it impede and slow down and endangers the deadline, which in turn is critical to the contract with the client, and lots of money is involded. Imagine a bad sprint, things are harsh, and for whaterver reason, 2 or 3 critical items are now back in the sprint, and things derail : a big client file in a complain to the VP ... which makes a reunion with departement director and the PO. PO is scared, and pulls a classic : "not my fault, dev didnt do the work correctly and if I had knew beforehand, it would not have happenned .. you know how THEY are ... ".
Fine, so the boss comes with the easy answer : " now the PO is the only one able to put a PBI to DONE ".
it's easy to get there in the wrong climate, the wrong cie environnement and values ... but even if the cie finally turns around and start working in a new, better way, the fact this rules was implemented a couple of years ago makes it 'how things work in here' ... and well, changing habits takes time.