<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Why Scrum Sprints Are Not Mini Waterfalls	</title>
	<atom:link href="https://www.scrumexpert.com/knowledge/why-scrum-sprints-are-not-mini-waterfall/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.scrumexpert.com/knowledge/why-scrum-sprints-are-not-mini-waterfall/</link>
	<description></description>
	<lastBuildDate>Thu, 09 Feb 2012 14:45:32 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: Gary Reynolds		</title>
		<link>https://www.scrumexpert.com/knowledge/why-scrum-sprints-are-not-mini-waterfall/#comment-575</link>

		<dc:creator><![CDATA[Gary Reynolds]]></dc:creator>
		<pubDate>Thu, 09 Feb 2012 14:45:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrumexpert.com/?p=928#comment-575</guid>

					<description><![CDATA[Personally, I would question whether point 3 (no change in scope during a sprint) should always be adhered to in a commercial environment. Things change, sometimes at short notice, and if that change means that what you&#039;re working on is either (a) no longer the priority or (b) no longer wanted by the customer, then clearly you need to take action.

One option is to cancel the sprint and re-plan, but there&#039;s an overhead involved in doing this. If the change in scope is relatively small, should teams need to go through the relatively costly exercise of planning another sprint?

I fleshed out my thoughts on this subject in more detail at: http://agileblog.garyreynolds.me.uk/2011/12/accepting-change-into-iteration.html

Thoughts?]]></description>
			<content:encoded><![CDATA[<p>Personally, I would question whether point 3 (no change in scope during a sprint) should always be adhered to in a commercial environment. Things change, sometimes at short notice, and if that change means that what you&#8217;re working on is either (a) no longer the priority or (b) no longer wanted by the customer, then clearly you need to take action.</p>
<p>One option is to cancel the sprint and re-plan, but there&#8217;s an overhead involved in doing this. If the change in scope is relatively small, should teams need to go through the relatively costly exercise of planning another sprint?</p>
<p>I fleshed out my thoughts on this subject in more detail at: <a href="http://agileblog.garyreynolds.me.uk/2011/12/accepting-change-into-iteration.html" rel="nofollow ugc">http://agileblog.garyreynolds.me.uk/2011/12/accepting-change-into-iteration.html</a></p>
<p>Thoughts?</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
