<?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: Specify Story, not details</title>
	<atom:link href="http://zenofnptech.org/2009/08/specify-story-not-details.html/feed" rel="self" type="application/rss+xml" />
	<link>http://zenofnptech.org/2009/08/specify-story-not-details.html</link>
	<description>Thoughtful and sometimes snarky perspectives on nonprofit technology</description>
	<lastBuildDate>Sun, 31 Jul 2011 12:25:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Brad</title>
		<link>http://zenofnptech.org/2009/08/specify-story-not-details.html/comment-page-1#comment-7328</link>
		<dc:creator>Brad</dc:creator>
		<pubDate>Tue, 12 Jan 2010 04:23:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.zenofnptech.org/?p=552#comment-7328</guid>
		<description>I see.  That makes sense, and I take your point then.  I agree with you 100% on your last point particularly.  A lot of frustration and misunderstanding can be avoided with good project management.  Well developed user stories can go a long way toward achieving that, so I do agree with your overall point for sure.

My argument also assumes that all contractors are  a) competent and  b) well intentioned and I think  we all know that in the real world that is not always the case. Though it is a foreign idea to me personally, I can conceive of contractors that would, through either a or b above, over sell and under deliver.

Obviously, it the the opposite of this that the competent, well intentioned contractor continuously strives for.</description>
		<content:encoded><![CDATA[<p>I see.  That makes sense, and I take your point then.  I agree with you 100% on your last point particularly.  A lot of frustration and misunderstanding can be avoided with good project management.  Well developed user stories can go a long way toward achieving that, so I do agree with your overall point for sure.</p>
<p>My argument also assumes that all contractors are  a) competent and  b) well intentioned and I think  we all know that in the real world that is not always the case. Though it is a foreign idea to me personally, I can conceive of contractors that would, through either a or b above, over sell and under deliver.</p>
<p>Obviously, it the the opposite of this that the competent, well intentioned contractor continuously strives for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://zenofnptech.org/2009/08/specify-story-not-details.html/comment-page-1#comment-7326</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Mon, 11 Jan 2010 19:27:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.zenofnptech.org/?p=552#comment-7326</guid>
		<description>The point is not to chastise contractors, nor expect anyone to do more than what was agreed upon. The point of the post was to shift some ways of thinking about what was agreed upon so that clients know exactly what they are getting functionally - they have a completed product that does what they want and expect, and the contractors get fairly paid for that result. 

My suggestion was that the way that things are often currently specified leads to a situation where clients are left with results that don&#039;t function as advertised, and need to end up spending more than they expect in order to get a functioning product.

And although I do think that intents do shift during the course of the project, it is important for contractors to track and flag those changes in intent, and be clear with the clients when they are out of scope.</description>
		<content:encoded><![CDATA[<p>The point is not to chastise contractors, nor expect anyone to do more than what was agreed upon. The point of the post was to shift some ways of thinking about what was agreed upon so that clients know exactly what they are getting functionally &#8211; they have a completed product that does what they want and expect, and the contractors get fairly paid for that result. </p>
<p>My suggestion was that the way that things are often currently specified leads to a situation where clients are left with results that don&#8217;t function as advertised, and need to end up spending more than they expect in order to get a functioning product.</p>
<p>And although I do think that intents do shift during the course of the project, it is important for contractors to track and flag those changes in intent, and be clear with the clients when they are out of scope.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brad</title>
		<link>http://zenofnptech.org/2009/08/specify-story-not-details.html/comment-page-1#comment-7325</link>
		<dc:creator>Brad</dc:creator>
		<pubDate>Mon, 11 Jan 2010 15:17:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.zenofnptech.org/?p=552#comment-7325</guid>
		<description>So, I am uncertain - how far does the &quot;intent&quot; of a contract go, and who gets to decide that?  It seems the point of a contract is to solidify and document &quot;intent,&quot; so that both parties have a clear understanding of what will be delivered.

It is very possible (and I suppose too common) for a clients &quot;intent&quot; to shift as a project progresses.  The contract should lay out very specifically what is expected of the contractor - this is the document by which they determine time estimates and resource needs.  To hold the contractor to some expectation of fulfilling unspoken, undocumented and uncontracted intentions that the client may have is unfair.  That would void the whole purpose of having a contract, wouldn&#039;t it?

This isn&#039;t to say that a contractor can&#039;t or shouldn&#039;t strive to go above and beyond.  But to chastise contractors in general for not doing more than what was agreed upon does not seem right, or good business practice for either side.</description>
		<content:encoded><![CDATA[<p>So, I am uncertain &#8211; how far does the &#8220;intent&#8221; of a contract go, and who gets to decide that?  It seems the point of a contract is to solidify and document &#8220;intent,&#8221; so that both parties have a clear understanding of what will be delivered.</p>
<p>It is very possible (and I suppose too common) for a clients &#8220;intent&#8221; to shift as a project progresses.  The contract should lay out very specifically what is expected of the contractor &#8211; this is the document by which they determine time estimates and resource needs.  To hold the contractor to some expectation of fulfilling unspoken, undocumented and uncontracted intentions that the client may have is unfair.  That would void the whole purpose of having a contract, wouldn&#8217;t it?</p>
<p>This isn&#8217;t to say that a contractor can&#8217;t or shouldn&#8217;t strive to go above and beyond.  But to chastise contractors in general for not doing more than what was agreed upon does not seem right, or good business practice for either side.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Heneise</title>
		<link>http://zenofnptech.org/2009/08/specify-story-not-details.html/comment-page-1#comment-7030</link>
		<dc:creator>Ryan Heneise</dc:creator>
		<pubDate>Wed, 19 Aug 2009 21:09:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.zenofnptech.org/?p=552#comment-7030</guid>
		<description>User stories are great for keeping a project on track. It&#039;s so easy to get caught up in details and implementation - especially for developers like me who really love sweating the small stuff. Stories are something that you can always reference as a project matures. Also, they&#039;re easy to write and don&#039;t require any technical knowledge - so any member of the project can say &quot;It should do xyz&quot;. I still have most of the stories that we started for the donor management and fundraising features of Donor Tools - and most of them are still relevant! A different developer might have solved the problems differently, but the stories gave me the flexibility to tackle the problems my way and come up with an innovative solution.</description>
		<content:encoded><![CDATA[<p>User stories are great for keeping a project on track. It&#8217;s so easy to get caught up in details and implementation &#8211; especially for developers like me who really love sweating the small stuff. Stories are something that you can always reference as a project matures. Also, they&#8217;re easy to write and don&#8217;t require any technical knowledge &#8211; so any member of the project can say &#8220;It should do xyz&#8221;. I still have most of the stories that we started for the donor management and fundraising features of Donor Tools &#8211; and most of them are still relevant! A different developer might have solved the problems differently, but the stories gave me the flexibility to tackle the problems my way and come up with an innovative solution.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

