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.
Luke Walter is an Agile Coach and Trainer at CollabNet, helping organizations maximize value delivery through agile development practices. Working with development teams, operations, and management, he helps them align for effectiveness; adopt more meaningful measures of progress; and overcome impediments to success. With a background in industrial design, Luke has 20 years of product development experience – over 14 of them in design management and user experience at consultancies and corporations including Microsoft and Getty Images. A Scrum practitioner since 2004, he’s logged over 8000 hours on high fidelity Scrum teams, amassing a rare wealth of real-world agile experience. Based in New York, he is a Scrum Alliance Certified Scrum Professional ®.
