A common misconception about the Product Owner is that he can indiscriminately change his mind about priorities or requirements at any time – including mid-sprint. I’ve had clients who clearly were excited at this liberating prospect, only to be disappointed upon clarification. If the Product Owner’s job is to maximize the return on investment of the development effort, why isn’t this true?
Because maximizing the ROI is achieved by various means, some of them having nothing to do with chasing every stakeholder whim or twist of the market weathervane. One of the primary reasons for fixing priority for the duration of the sprint is to protect the delivery team from being randomized into ineffectiveness.
The usual lightning rod for this issue is the question of when to terminate a sprint. Isn’t it within the Product Owner’s authority to do this? When exactly should a PO exercise this power? The commonly accepted phrase for this practice is “Abnormally terminating a sprint”, meaning not that there are abnormal vs normal reasons for doing so, but rather that terminating a sprint at all should be an abnormal occurrence; unusual, rare.
If the business value of the sprint commitment has changed since Sprint Planning such that when finished the Sprint Commitment would no longer present sufficient ROI relative to other emergent needs, the PO may terminate a sprint. But a conscientious PO will only do this in extreme cases, NOT every time realities change – because they’re always changing. It’s the PO’s job to manage discovered change and regularly incorporate it into the backlog so that the productivity of the team is unimpeded and represents consistently high business value. Terminating a sprint is definitely a business decision, but it shouldn’t be made lightly because of the damage it can do to productivity, team morale, and cadence.
Over time, this cadence and shelter from distraction and interference have follow-on effects beyond the outcome of any one individual sprint. A PO who fails to respect this and is always terminating sprints to reprioritize in-process work is shooting himself in the foot; He’ll likely see very little productivity from the Team, and probably realize no value from ‘doing’ Scrum. This isn’t a fault of Scrum – it’s the PO’s fault.