<?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"
	>
<channel>
	<title>Comments on: Estimation Units Predict Schedule Slippage</title>
	<atom:link href="http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html/feed" rel="self" type="application/rss+xml" />
	<link>http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html</link>
	<description>Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.</description>
	<pubDate>Mon, 08 Sep 2008 07:06:50 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: John Salch</title>
		<link>http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html#comment-1272</link>
		<dc:creator>John Salch</dc:creator>
		<pubDate>Thu, 22 Nov 2007 17:30:04 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html#comment-1272</guid>
		<description>I agree, as well.  However, I have also found that estimates can be too small.  Certainly weeks is too big, but estimating how long you will spend doing a single check-in (maybe 2 minutes) of a file is too small.

Estimation takes effort and time.  The more granular, the more time it requires.  There should always be an "effort vs. value" thought process applied.

One other aspect to consider is that the more granular the estimate, the more perfect it is expected to be, and thus the more resistant to change people become.  Story points can be handy here, or "perfect engineering days/minutes/hours".

Care must be taken in these processes.  Small iterations, such as 1 week (in XP), really help.  Detailed planning can be done but only for a short horizon.  Less granular planning can be done over longer horizons...

For more information on all of this, Mike Cohn's book "Agile Estimating and Planning" is a great resource...</description>
		<content:encoded><![CDATA[<p>I agree, as well.  However, I have also found that estimates can be too small.  Certainly weeks is too big, but estimating how long you will spend doing a single check-in (maybe 2 minutes) of a file is too small.</p>
<p>Estimation takes effort and time.  The more granular, the more time it requires.  There should always be an &#8220;effort vs. value&#8221; thought process applied.</p>
<p>One other aspect to consider is that the more granular the estimate, the more perfect it is expected to be, and thus the more resistant to change people become.  Story points can be handy here, or &#8220;perfect engineering days/minutes/hours&#8221;.</p>
<p>Care must be taken in these processes.  Small iterations, such as 1 week (in XP), really help.  Detailed planning can be done but only for a short horizon.  Less granular planning can be done over longer horizons&#8230;</p>
<p>For more information on all of this, Mike Cohn&#8217;s book &#8220;Agile Estimating and Planning&#8221; is a great resource&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dwayne Phillips</title>
		<link>http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html#comment-1270</link>
		<dc:creator>Dwayne Phillips</dc:creator>
		<pubDate>Thu, 22 Nov 2007 14:14:18 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/2007/11/estimation-units-predict-schedule-slippage.html#comment-1270</guid>
		<description>I agree. The last major project I worked started with the manager stating that the smallest task on the project was 400-person-hours long. One person working ten weeks - that was the SMALLEST task.

Many schedule problems ensued over the next two years.

Finally, we replanned the project. We worked hard at monitoring each individual day in the work. Everything finished on time or ahead of time.

Why didn't we do this day-by-day planning at the start? No one wanted to do that. It was so much work and it didn't seem to make any sense.</description>
		<content:encoded><![CDATA[<p>I agree. The last major project I worked started with the manager stating that the smallest task on the project was 400-person-hours long. One person working ten weeks - that was the SMALLEST task.</p>
<p>Many schedule problems ensued over the next two years.</p>
<p>Finally, we replanned the project. We worked hard at monitoring each individual day in the work. Everything finished on time or ahead of time.</p>
<p>Why didn&#8217;t we do this day-by-day planning at the start? No one wanted to do that. It was so much work and it didn&#8217;t seem to make any sense.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
