When is it okay to terminate a sprint?

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

Luke Walter is a Certified Scrum Trainer® and Agile Coach, helping organizations maximize value delivery using the Scrum framework and Agile development practices. He guides senior management, development, and operations through the challenges intrinsic to agile adoptions, enabling them to adopt more meaningful measures of progress and realign for effectiveness. A 9-year Scrum veteran with over 8000 hours logged on high-performing Scrum teams, he brings an uncommon depth of real-world agile experience to organizations seeking to transcend procedural and cultural barriers to success.

Tagged with:
Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
   Contact Us
sign up for emails
conversations

CollabNet: Upcoming webinar: #Git #Gerrit with TeamForge: Secure, Scalable, Standards-Compliant for the Enterprise http://t.co/SZC9PvFIP5
Date: 28 August 2014 | 6:00 pm

CollabNet: Join me and @CollabNet: for this free #Agile Guru Q&A with CSP Caleb Brown http://t.co/urUr1deQqN
Date: 25 August 2014 | 8:15 pm

CollabNet: Be sure to register for our #CertifiedScrumProductOwner class in South San Francisco on Aug 27-28 w/ Gregory Smith! http://t.co/5OhlMBGWoy
Date: 22 August 2014 | 7:00 pm