<?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: What? You mean, for free?</title>
	<atom:link href="http://www.udidahan.com/2007/01/24/what-you-mean-for-free/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.udidahan.com/2007/01/24/what-you-mean-for-free/</link>
	<description>Enterprise Development Expert &#38; SOA Specialist</description>
	<lastBuildDate>Sat, 11 Feb 2012 15:16:10 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Daniel Hoey</title>
		<link>http://www.udidahan.com/2007/01/24/what-you-mean-for-free/comment-page-1/#comment-384</link>
		<dc:creator>Daniel Hoey</dc:creator>
		<pubDate>Thu, 25 Jan 2007 07:38:35 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/369#comment-384</guid>
		<description>Udi,

I agree that it is important to know when to say no to a client request. How you say it is important as well (your long version is perfect). However, from my understanding none of the agile processes advocate dropping a feature that is mid development to allow the addition of some new feature. This is what iterations are for; they provide regular times when the feature list can be modified and re-prioritized. Mid iteration, any request to add a new feature should result in the response: &quot;We can add it to the feature set for the next iteration&quot;. 

If there is no next iteration then my answer is the same as yours: “no”. I believe that by providing explicit times throughout development to review the state of the system and add new requirements (as agile projects do at the start of an iteration) it is less likely that an important requirement would be left till the end of the project, making it much less likely that I will be in a position of having to say no.

Dan</description>
		<content:encoded><![CDATA[<p>Udi,</p>
<p>I agree that it is important to know when to say no to a client request. How you say it is important as well (your long version is perfect). However, from my understanding none of the agile processes advocate dropping a feature that is mid development to allow the addition of some new feature. This is what iterations are for; they provide regular times when the feature list can be modified and re-prioritized. Mid iteration, any request to add a new feature should result in the response: &#8220;We can add it to the feature set for the next iteration&#8221;. </p>
<p>If there is no next iteration then my answer is the same as yours: “no”. I believe that by providing explicit times throughout development to review the state of the system and add new requirements (as agile projects do at the start of an iteration) it is less likely that an important requirement would be left till the end of the project, making it much less likely that I will be in a position of having to say no.</p>
<p>Dan</p>
]]></content:encoded>
	</item>
</channel>
</rss>

