<?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: How Big Are Your Buffers?</title>
	<atom:link href="http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html</link>
	<description>Dealing with software projects in real life</description>
	<lastBuildDate>Fri, 10 Feb 2012 19:07:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html#comment-2063</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Fri, 12 Dec 2008 10:32:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html#comment-2063</guid>
		<description>Depending on situation we use anything between -50% (yes, a negative buffer) to 100%. A negative buffer is when a salesperson come and say:&lt;br/&gt;- Hey, they won&#039;t buy it with that schedule.&lt;br/&gt;We answer:&lt;br/&gt;- Hey, we won&#039;t deliver much faster.&lt;br/&gt;- What can we do?&lt;br/&gt;- You know, we can cut the schedule but it won&#039;t make us deliver faster. Then you and I will have to go to the customer and tell qhy we&#039;re late.&lt;br/&gt;- That&#039;s a good plan. Do it.&lt;br/&gt;&lt;br/&gt;For pure development tasks we use usually something between 20% and 30%. It can be modified (increased) by factors of &quot;freshness&quot; of a developer, poor track record in estimating, a high number of expected interruptions etc.&lt;br/&gt;&lt;br/&gt;Sometimes we use rough scheduling technique when we use 100% buffer but we include testing and implementation in buffer. This we do usually for standard tasks which we don&#039;t expect much uncertainty in (change requests etc).</description>
		<content:encoded><![CDATA[<p>Depending on situation we use anything between -50% (yes, a negative buffer) to 100%. A negative buffer is when a salesperson come and say:<br />- Hey, they won&#8217;t buy it with that schedule.<br />We answer:<br />- Hey, we won&#8217;t deliver much faster.<br />- What can we do?<br />- You know, we can cut the schedule but it won&#8217;t make us deliver faster. Then you and I will have to go to the customer and tell qhy we&#8217;re late.<br />- That&#8217;s a good plan. Do it.</p>
<p>For pure development tasks we use usually something between 20% and 30%. It can be modified (increased) by factors of &#8220;freshness&#8221; of a developer, poor track record in estimating, a high number of expected interruptions etc.</p>
<p>Sometimes we use rough scheduling technique when we use 100% buffer but we include testing and implementation in buffer. This we do usually for standard tasks which we don&#8217;t expect much uncertainty in (change requests etc).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: yatsevsky</title>
		<link>http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html#comment-2062</link>
		<dc:creator>yatsevsky</dc:creator>
		<pubDate>Thu, 11 Dec 2008 22:03:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/2008/12/how-big-are-your-buffers.html#comment-2062</guid>
		<description>Usually we make laughs over multiplying developers estimate on &quot;pi&quot; number and in a more rare cases, on &quot;e&quot;. =))) But usually buffer is 25-30%. What&#039;s yours?</description>
		<content:encoded><![CDATA[<p>Usually we make laughs over multiplying developers estimate on &#8220;pi&#8221; number and in a more rare cases, on &#8220;e&#8221;. =))) But usually buffer is 25-30%. What&#8217;s yours?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

