Product owners that define acceptance criteria then refuse it!

A few questions:

1. Is the Product Owner seeing any of the functionality delivered as part of the user story between the start of the sprint and the Sprint Review?

Regular discussion and feedback from the Product Owner would catch this type of issue earlier in the sprint.

The Sprint Review is not where the Product Owner accepts the completion of a User Story. This should be done before the Review.

2. Is the criteria in the scope of the initial user story? It would be up to the development team (I think) to determine if it's part of the user story or not. If it's not, then you can work with the Product Owner to create a new user story to capture their additional work.

If you have a deadline to work towards, then it's the scope that must be flexible (or the cost).

The problem is when the P.O. refuses, and asks for adding extra criteria!!

That statement indicates that he is asking for new functionality beyond what was originally agreed upon.  That is a new story.  If your Development Team has delivered the original agreed understanding, then the PO should be adding new stories for the new functionality being requested. 

As @Ben states, the PO should be seeing the work along the way in order to honor Scrum values. 

A few things from the Scrum Guide (emphasis by me)

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

This is not a place for the Product Owner to accept/reject work. It is a place for inspecting and discussing the potentially releasable increment created and adjust future plans. This can also be the place at which the Product Owner decides if this is in fact releasable.  If based on new requirements the date from your RFP needs to be adjusted, then it is the Product Owner's responsibility to do so.  In my past experience with working on both sides of an RFP, it is usually understood that new requirements can result in changes to anything stated in the RFP. 

 Ben Brumm

If you have a deadline to work towards, then it's the scope that must be flexible (or the cost).

Yes Ben Brumm, there should be flexibility on cost, and this is the benefit on change request.

The change request is used to approve that the late was because of a reason that out of my team, AND to ask for extra cost in some cases.

Daniel Wilhite

In my past experience with working on both sides of an RFP, it is usually understood that new requirements can result in changes to anything stated in the RFP. 

Some RFPs give only high level requirements, so any update on U.S. by adding, updating or deleting won’t rebut the RPP

In our projects, RFPs defined that the period will be 6 months, and there will a subtract by 5% per late month

We have a DEADLINE that has been identified in the RFP

Who committed to that deadline, and on the basis of what evidence?

A Scrum Development Team might commit to a delivery deadline at the end of each Sprint.

 Ian Mitchell

Who committed to that deadline, and on the basis of what evidence?

In some countries (including my country) the RFP is written by the company of the user, let we call it company A.

Then the developers will be in another company, let we call it company B.

Sometimes, the projects will be managed by company C.

In my question, the product owner is in A.

Scrum master & development team are in B

When Product Owner/Scrum Master/Development Team belong to different companies and maybe different sites things often get more complex.

As I remember Craig Larman has some excellent resoucres on Multisite/Onshore/Offshore software development with Scrum. 

Jörg Häcker

As I remember Craig Larman has some excellent resoucres on Multisite/Onshore/Offshore software development with Scrum. 

Thanks for care

Plz, give the link for Those resources

Best Wishes

I recommend his book "Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum".

In some countries (including my country) the RFP is written by the company of the user, let we call it company A.

Then the developers will be in another company, let we call it company B.

Sometimes, the projects will be managed by company C.

In my question, the product owner is in A.

Scrum master & development team are in B

So it seems like Company A(the user, the author of the RFP) is the requiring the change in scope. Since that is the case you should be transparent with the problem and let them and your company's leaders know that Company A is asking for things that were not included in the original statement of work.  As I said, RFP can be changed based on that situation. Your company (B) should have some leadership that can handle those negotiations with the other company. The Development Team should be building based on the information they were given. If the acceptance criteria in the original story is met, you are "done" with that story.  Then you can iterate on that deliverable to provide the next potentially releasable increment. New requirements should be introduced as new stories not as new acceptance criteria given at the Review. As Scum Master your job will be to escalate the issue so that your company management can work to remove the impediment that is being presented to your team.

As I said originally, if based on new requirements the date from your RFP needs to be adjusted, then it is the Product Owner's responsibility to do so.  In your case, you have a Product Owner that is refusing to do their job and is causing an impediment. How can you remove that impediment? 

Daniel Wilhite

Thanks for your valuable answer that shoed many good points, like the following:

Company (B) should have some leadership that can handle those negotiations with the other company

 the date from your RFP needs to be adjusted, 

In your case, you have a Product Owner that is refusing to do their job 

So, we must discus with A to convince them kindly to incur the responsibility of updating the Dead line

Many thanks

Ripple Man,

The 4th Agile Principle states:

Business people and developers must work together daily throughout the project.

Is this happening, or not happening, in your situation?

Timothy Baffa

Thanks for your smart question

The answer is NO

We got the requirements for the sprint... Then we develop it without users involvements

After all, and during sprint review, the problems happen where P.O. orders adding/updating some acceptance criteria

the problems happen where P.O. orders adding/updating some acceptance criteria

A few questions then that you may want to pose to your business area / organization:

1. How can you support the 4th Agile Principle?   What issues might there be stemming from not adhering to the 4th principle?
2. What are some ways you can curtail "moving the goal posts" on the Development Team?   How does changing acceptance criteria mid-sprint or end-of-sprint help or hurt predictability around what the Development Team can deliver?

 Timothy Baffa

Thanks for your reply

I will answer your questions by one question

In our situation, where Company A contains the users and P.O. and company B where development team and scrum master

how can we apply principle 4 of agile especially that A & B are in different places and many users are academic people that spends many hours with students

The P.O. told that most requirements are with those users and he faced many difficulties to meet them