<?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: Software cost estimation: Where&#8217;s the silver bullet?</title>
	<atom:link href="http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/</link>
	<description>Making Scrum work: informal discussions on process improvement</description>
	<lastBuildDate>Fri, 04 Jun 2010 16:55:49 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=9944</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Arlene Minkiewicz</title>
		<link>http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/comment-page-1/#comment-7</link>
		<dc:creator>Arlene Minkiewicz</dc:creator>
		<pubDate>Mon, 27 Oct 2008 17:58:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.rational-scrum.com/?p=53#comment-7</guid>
		<description>Software estimation is hard and there is no silver bullet.  I build software estimation models and quite frankly, if I tried to sell you a silver bullet you would laugh me out of the room exactly because you know software estimation is hard.  The reasons it is hard are many, some of which you have mentioned above and some of which I have detailed in my article &quot;Agile Developement and Software Estimation&quot; (found at http://blog.pricesystems.com/blog/arlene-on-accurate-estimating).  
But as you note, software estimation is crucial to project success.  And as the provider of tools I would certainly advocate the inclusion of a good tool into the software estimation process.  But don&#039;t expect the tool to be a silver bullet - rather it isa way to enforce a methodology not only for estimation but for proceeding forward with successful data collection and future project estimation success. It doesn&#039;t matter how good the tool is - without good data it will not be &#039;right&#039; out of the box But it will, out of the box, help create that infrastructure necessary for data collection by intimating what things are important to collect and what buckets are best for collection of effort and schedule information.  Additionally, as noted in the article of my colleague, &quot;The Silver Bullet - Practice Makes Perfect&quot; (found at http://blog.pricesystems.com/blog/price-systems) the only way to move from immature estimating practices to more mature estimating practices is through practice. 
Certainly I am an advocate for the value of tools in this process - they help speed the adoption of good estimating practices and ultimately speed up the estimation process itslef.  But even in a small start up - where tools may not be deemed a worthwhile investment - establishing a rudimentary process that feeds itself through data collection and comparison of estimates to actuals - will - in relatively short term - pay for itself in greater confidence in the outcomes. It will be easier to identify &#039;comparable&#039; projects, data collection will be facilitated with knowledge of what data to collect , and confidence in the value of estimation will be engendered up and down the chain.</description>
		<content:encoded><![CDATA[<p>Software estimation is hard and there is no silver bullet.  I build software estimation models and quite frankly, if I tried to sell you a silver bullet you would laugh me out of the room exactly because you know software estimation is hard.  The reasons it is hard are many, some of which you have mentioned above and some of which I have detailed in my article &#8220;Agile Developement and Software Estimation&#8221; (found at <a href="http://blog.pricesystems.com/blog/arlene-on-accurate-estimating)" rel="nofollow">http://blog.pricesystems.com/blog/arlene-on-accurate-estimating)</a>.<br />
But as you note, software estimation is crucial to project success.  And as the provider of tools I would certainly advocate the inclusion of a good tool into the software estimation process.  But don&#8217;t expect the tool to be a silver bullet &#8211; rather it isa way to enforce a methodology not only for estimation but for proceeding forward with successful data collection and future project estimation success. It doesn&#8217;t matter how good the tool is &#8211; without good data it will not be &#8216;right&#8217; out of the box But it will, out of the box, help create that infrastructure necessary for data collection by intimating what things are important to collect and what buckets are best for collection of effort and schedule information.  Additionally, as noted in the article of my colleague, &#8220;The Silver Bullet &#8211; Practice Makes Perfect&#8221; (found at <a href="http://blog.pricesystems.com/blog/price-systems)" rel="nofollow">http://blog.pricesystems.com/blog/price-systems)</a> the only way to move from immature estimating practices to more mature estimating practices is through practice.<br />
Certainly I am an advocate for the value of tools in this process &#8211; they help speed the adoption of good estimating practices and ultimately speed up the estimation process itslef.  But even in a small start up &#8211; where tools may not be deemed a worthwhile investment &#8211; establishing a rudimentary process that feeds itself through data collection and comparison of estimates to actuals &#8211; will &#8211; in relatively short term &#8211; pay for itself in greater confidence in the outcomes. It will be easier to identify &#8216;comparable&#8217; projects, data collection will be facilitated with knowledge of what data to collect , and confidence in the value of estimation will be engendered up and down the chain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kirk Gray</title>
		<link>http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/comment-page-1/#comment-6</link>
		<dc:creator>Kirk Gray</dc:creator>
		<pubDate>Mon, 20 Oct 2008 19:58:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.rational-scrum.com/?p=53#comment-6</guid>
		<description>Fortunately I am not in that situation now - but I have been.  It&#039;s harder when economics are as they are to convince people to make investments in less-tangible endeavours, but I understand what you are saying.</description>
		<content:encoded><![CDATA[<p>Fortunately I am not in that situation now &#8211; but I have been.  It&#8217;s harder when economics are as they are to convince people to make investments in less-tangible endeavours, but I understand what you are saying.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: zbeckman</title>
		<link>http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/comment-page-1/#comment-5</link>
		<dc:creator>zbeckman</dc:creator>
		<pubDate>Wed, 15 Oct 2008 15:01:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.rational-scrum.com/?p=53#comment-5</guid>
		<description>It&#039;s unfortunate that you&#039;re in a situation where the people relying on you would laugh you out of the room. I&#039;ve been there a few times -- and as I mentioned above, quite frankly I&#039;d be looking for a new employer that places a higher value on your expertise. However, that said, I&#039;ll add that the best weapon you can use against this is to present your boss with choices: Tell him outright, &quot;we need a consultant to help us improve our process; without one, there&#039;s no point in setting a release date because we simply don&#039;t have the ability to make it reliable.&quot; Redirect the decision to the business, with clear emphasis on the consequences. That way, the business is the one that must decide, consciously, to go down a sub-optimal path. Most often, it at least opens up a dialogue about other options.</description>
		<content:encoded><![CDATA[<p>It&#8217;s unfortunate that you&#8217;re in a situation where the people relying on you would laugh you out of the room. I&#8217;ve been there a few times &#8212; and as I mentioned above, quite frankly I&#8217;d be looking for a new employer that places a higher value on your expertise. However, that said, I&#8217;ll add that the best weapon you can use against this is to present your boss with choices: Tell him outright, &#8220;we need a consultant to help us improve our process; without one, there&#8217;s no point in setting a release date because we simply don&#8217;t have the ability to make it reliable.&#8221; Redirect the decision to the business, with clear emphasis on the consequences. That way, the business is the one that must decide, consciously, to go down a sub-optimal path. Most often, it at least opens up a dialogue about other options.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kirk Gray</title>
		<link>http://www.rational-scrum.com/2008/10/software-cost-estimation-wheres-the-silver-bullet/comment-page-1/#comment-4</link>
		<dc:creator>Kirk Gray</dc:creator>
		<pubDate>Mon, 13 Oct 2008 16:26:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.rational-scrum.com/?p=53#comment-4</guid>
		<description>I do agree with most of what you say.  I think that there *absolutely are* a lot of things that we could do.  I think that in addition to what I mentioned as issues in my post, a big issue is this:

Some web startups are software companies, and some web startups are &#039;businesses&#039;.  

Now, the distinction shouldn&#039;t necessarily exist - all startups are (obviously) businesses, and generally web startups are software companies (technology drives most of their value proposition).  The thing is, if I requested a budget line item to bring in a consultant or to implement JIRA (wouldn&#039;t that be nice, though we do use Unfuddle which is better than nothing), I would possibly be laughed out of the room because that money would be better spent on direct marketing or traffic sharing or business development.

I guess it depends who the leader is and what their background is, to decide whether buy-in at that level is feasible or not.  Nobody is wrong, just a perspective thing.  I will take a look at some of the suggestions, and some of the many posts on your blog and maybe try to take some baby steps =)</description>
		<content:encoded><![CDATA[<p>I do agree with most of what you say.  I think that there *absolutely are* a lot of things that we could do.  I think that in addition to what I mentioned as issues in my post, a big issue is this:</p>
<p>Some web startups are software companies, and some web startups are &#8216;businesses&#8217;.  </p>
<p>Now, the distinction shouldn&#8217;t necessarily exist &#8211; all startups are (obviously) businesses, and generally web startups are software companies (technology drives most of their value proposition).  The thing is, if I requested a budget line item to bring in a consultant or to implement JIRA (wouldn&#8217;t that be nice, though we do use Unfuddle which is better than nothing), I would possibly be laughed out of the room because that money would be better spent on direct marketing or traffic sharing or business development.</p>
<p>I guess it depends who the leader is and what their background is, to decide whether buy-in at that level is feasible or not.  Nobody is wrong, just a perspective thing.  I will take a look at some of the suggestions, and some of the many posts on your blog and maybe try to take some baby steps =)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
