<?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: Does our intuition fail us?</title>
	<atom:link href="http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/</link>
	<description>The neglected essentials of software development</description>
	<lastBuildDate>Fri, 03 Feb 2012 07:28:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/comment-page-1/#comment-13</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Sun, 23 May 2010 20:06:23 +0000</pubDate>
		<guid isPermaLink="false">http://localhost/AgileKiwiWordpress/?p=14#comment-13</guid>
		<description>Thanks.  Nice way to help people understand the concept.</description>
		<content:encoded><![CDATA[<p>Thanks.  Nice way to help people understand the concept.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bevan Arps</title>
		<link>http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/comment-page-1/#comment-12</link>
		<dc:creator>Bevan Arps</dc:creator>
		<pubDate>Sun, 23 May 2010 10:39:09 +0000</pubDate>
		<guid isPermaLink="false">http://localhost/AgileKiwiWordpress/?p=14#comment-12</guid>
		<description>A colleague of mine suggested a technique that&#039;s worked very well on a current project. Borrowing from Cricket, our project &quot;dashboard&quot; includes a &quot;Run Rate&quot; graph.

The RunRate graph is a simple column chart produced by Excel. (Pity I can&#039;t show a picture here).

The first column (&quot;Estimated&quot;) is the number of accumulated hours per day that we assumed when we took our effort estimates and turned them into a timeline.

The second column (&quot;Actual&quot;) is the number of hours per day of actual effort we&#039;ve expended on the project (so, this doesn&#039;t count production support, completing timecards, team meetings etc).

The third column (&quot;Required&quot;) is the number of hours per day of effort we need if we are to hit the target date.

Works really well - easy to explain to anyone, and easy for them to interpret reliabily.</description>
		<content:encoded><![CDATA[<p>A colleague of mine suggested a technique that&#8217;s worked very well on a current project. Borrowing from Cricket, our project &#8220;dashboard&#8221; includes a &#8220;Run Rate&#8221; graph.</p>
<p>The RunRate graph is a simple column chart produced by Excel. (Pity I can&#8217;t show a picture here).</p>
<p>The first column (&#8220;Estimated&#8221;) is the number of accumulated hours per day that we assumed when we took our effort estimates and turned them into a timeline.</p>
<p>The second column (&#8220;Actual&#8221;) is the number of hours per day of actual effort we&#8217;ve expended on the project (so, this doesn&#8217;t count production support, completing timecards, team meetings etc).</p>
<p>The third column (&#8220;Required&#8221;) is the number of hours per day of effort we need if we are to hit the target date.</p>
<p>Works really well &#8211; easy to explain to anyone, and easy for them to interpret reliabily.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/comment-page-1/#comment-4</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Tue, 26 Jan 2010 11:39:48 +0000</pubDate>
		<guid isPermaLink="false">http://localhost/AgileKiwiWordpress/?p=14#comment-4</guid>
		<description>I agree, in that speed-ups of about 20% or more are probably impossible if the team is &quot;healthy&quot; to start with.</description>
		<content:encoded><![CDATA[<p>I agree, in that speed-ups of about 20% or more are probably impossible if the team is &quot;healthy&quot; to start with.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://www.agilekiwi.com/earnedvalue/does-our-intuition-fail-us/comment-page-1/#comment-5</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Sun, 24 Jan 2010 02:13:25 +0000</pubDate>
		<guid isPermaLink="false">http://localhost/AgileKiwiWordpress/?p=14#comment-5</guid>
		<description>I would go even further. In vast majority of cases teams can&#039;t really speed up by 20%. That just almost never happens in healthy work environments.&lt;br /&gt;&lt;br /&gt;Usually the problem is estimating. Estimates are usually too small but it is to be expected. We rarely take effort to make them real, either with reliable velocity measurement or with proper statistical analysis of past records.&lt;br /&gt;&lt;br /&gt;Now, if our estimates are wrong in the first half of the project they aren&#039;t going to be any better in the second part. The team will still be losing distance regularly.&lt;br /&gt;&lt;br /&gt;As a side note: I know teams which can speed up by 100% or more in terms of productivity but this is nothing you&#039;d call a healthy work environment. Actually it is very poor management which created incentive to have very poor results in the first part of the project so when people get back to their normal speed velocity skyrockets. Anyway that&#039;s the subject for a different story.</description>
		<content:encoded><![CDATA[<p>I would go even further. In vast majority of cases teams can&#39;t really speed up by 20%. That just almost never happens in healthy work environments.</p>
<p>Usually the problem is estimating. Estimates are usually too small but it is to be expected. We rarely take effort to make them real, either with reliable velocity measurement or with proper statistical analysis of past records.</p>
<p>Now, if our estimates are wrong in the first half of the project they aren&#39;t going to be any better in the second part. The team will still be losing distance regularly.</p>
<p>As a side note: I know teams which can speed up by 100% or more in terms of productivity but this is nothing you&#39;d call a healthy work environment. Actually it is very poor management which created incentive to have very poor results in the first part of the project so when people get back to their normal speed velocity skyrockets. Anyway that&#39;s the subject for a different story.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

