But in a company, it’s not just the PO’s money. It’s you and your team member’s money and time too. And I think you have a responsibility, as professional, to educate your PO if needed. They hired you as an expert to solve a problem. After all, people usually listen to doctor’s too and trust them as experts. Why not trust the engineers you hire? On the other hand, PO’s who don’t give a damn and are only marginally interested in a project are an annoyance too. The sort your organization picks by random.

The problem with aborting sprints is that it can set a precedent. There is often constant change in a project. What change is severe enough to justify abort? If aborting becomes the norm, the cycles between producing a deliverable cannot be planned any more. You will end up with an unpredictable release cycle, the thing you wanted to avoid by adopting Scrum. i.e. there’s no constant time between release dates. If you really want to abort sprints, then I think you need very very tight rules, which ensure aborts are well justified and are an exception.

But in the end I think the problem lies with the relationship with the PO, and not the way sprints are handled.