Your Scrum implementation has some misconceptions, which appear to be based around how to implement the "Definition of Done" in a properly-collaborative fashion. If you address this communications failure, your continuous integration efforts should become much smoother.
In addition, it will help your team a great deal to focus on the iterative nature of agile methodologies; agility stresses refinement of the product over time, rather than on perfect execution of "specifications" within each increment. The Product Backlog is a living document, and stories on the backlog are added, changed, or removed at least every iteration. It is not a one-pass set of requirements, and your team needs to leverage that flexibility.
When is Something Done?
In Scrum, a user story or increment is considered done when it has achieved its stated goal and met any existing criteria to which the Scrum Team as a whole (which includes the Product Owner) has previously agreed.
Consider the following user story:
As a web-browsing customer,
I want to see everything on the page in 300-point type
so that I don't suffer from eye strain.
This story would be done when:
- The web site's default font had been set to a ridiculous size.
- The team agrees that the implementation meets the goal of avoiding eye strain.
The current "Definition of Done," which applies to all stories in the project, has been met. This definition varies from team to team, but might include unit tests, user acceptance tests, pushing to a continuous integration server, or slapping each other with wet mackerel. Whatever.
NB: The point here is that the team (including the Product Owner) agrees to the definition beforehand. There is no post-facto retconning of "Done."
Someone on the team marks the story "done" on the Sprint Backlog.
That's it. The story is now done. It may or may not be done right, but it's considered complete for the purposes of Scrum. The Product Owner should have been involved throughout the Sprint, so if the feature has completely slid off the rails, the PO's lack of involvement is likely the problem and should be addressed during the next Sprint Retrospective.
What About Stories That Aren't Done Right?
At the end of the Sprint, the team collects points for all stories that the whole team (including the Product Owner) agree were completed according to the Definition of Done. If the stories were thus completed, but are unsatisfactory in some way, that's grist for the mill during the Sprint Retrospective and for other inspect-and-adapt meetings. It doesn't change the fact that the stories were done in an agreed-upon way—an agreement to which the Product Owner was an active party—and so there's no "acceptance" of the stories to be done.
However, during the Sprint Review (my exposition in bold):
- The Product Owner explains [to stakeholders] what Product Backlog items have been “Done” and what has not been “Done”. This is a status report, not an opportunity to accept or decline stories.
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment. This is often a great place to explain misfeatures that are nevertheless "Done," and to solicit stakeholder feedback about how to improve them in a future iteration.
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed). This is another inflection point where stakeholders can decide if an imperfect feature is "good enough," or if it needs to be reworked or added back to the Product Backlog as-is.
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning. This is where some limited discussion of misfeatures could take place, but most process problems should be addressed in the Sprint Retrospective.
Then, during Backlog Refinement or Sprint Planning, the Product Owner can take any stories that were completed but didn't deliver the desired value and:
- Write new stories to address any shortcomings.
- Put stories back onto the Product Backlog, hopefully with more detail or a better understanding with the team of the story's goals and objectives.
- Decide that the features, as delivered, are "good enough" or don't need to be iterated over again.
To sum up, the Product Owner doesn't get to single-handedly declare whether or not a story is done. After all, the "definition of done" is a collaboration between all the members of the Scrum Team.
However, the Product Owner (as the sole custodian of the Product Backlog) does get to determine if a story can be marked completed on the Product Backlog or if elements of it need to be done again in another Sprint. Simply throwing the original story back onto the top of the Product Backlog without addressing the underlying problems with the story, the Scrum process, or the Scrum Team's communication is probably a bad idea though, so the Scrum Master should definitely assist at that point.