<?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: Four Methods of Perfecting Agile</title>
	<atom:link href="http://www.agileadvice.com/2007/09/06/agilemanagement/four-methods-of-perfecting-agile/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agileadvice.com/2007/09/06/agilemanagement/four-methods-of-perfecting-agile/</link>
	<description></description>
	<pubDate>Sun, 23 Nov 2008 18:17:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: admin</title>
		<link>http://www.agileadvice.com/2007/09/06/agilemanagement/four-methods-of-perfecting-agile/#comment-1920</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Fri, 11 Jul 2008 22:15:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileadvice.com/2007/09/06/uncategorized/four-methods-of-perfecting-agile/#comment-1920</guid>
		<description>Measuring completeness is impossible no matter what method one is using unless you are building something that will _never_ be changed in the future... which as we all know is just not the way software systems work.

That said, from a project perspective, progress is easy to measure in agile methods using velocity and a release or project burndown chart.  Basically, the work that the team does and will do in the future is measured in size and value and then chunked up into Sprints (iterations/cycles).  At the end of each cycle, the team delivers something potentially shippable and there is a certain amount remaining.  This remaining amount can be tracked cycle by cycle to produce a burndown chart.  The slope of this chart will allow you to determine the point where it will get to zero remaining work and this is your progress measurement.

Also, as for dedicated teams, you are partially correct: agile works best with dedicated teams... but that is true for any method!  Dedicated teams are superior to shared team members under all circumstances when measuring for value delivered over time.  I challenge you to work the numbers to see what I mean!</description>
		<content:encoded><![CDATA[<p>Measuring completeness is impossible no matter what method one is using unless you are building something that will _never_ be changed in the future&#8230; which as we all know is just not the way software systems work.</p>
<p>That said, from a project perspective, progress is easy to measure in agile methods using velocity and a release or project burndown chart.  Basically, the work that the team does and will do in the future is measured in size and value and then chunked up into Sprints (iterations/cycles).  At the end of each cycle, the team delivers something potentially shippable and there is a certain amount remaining.  This remaining amount can be tracked cycle by cycle to produce a burndown chart.  The slope of this chart will allow you to determine the point where it will get to zero remaining work and this is your progress measurement.</p>
<p>Also, as for dedicated teams, you are partially correct: agile works best with dedicated teams&#8230; but that is true for any method!  Dedicated teams are superior to shared team members under all circumstances when measuring for value delivered over time.  I challenge you to work the numbers to see what I mean!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aver406</title>
		<link>http://www.agileadvice.com/2007/09/06/agilemanagement/four-methods-of-perfecting-agile/#comment-1917</link>
		<dc:creator>aver406</dc:creator>
		<pubDate>Fri, 11 Jul 2008 12:58:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileadvice.com/2007/09/06/uncategorized/four-methods-of-perfecting-agile/#comment-1917</guid>
		<description>Mishkin:
One question that comes up as a Project manager is "how do you measure completeness" with Agile? So often MS Project can't accurately reflect how far along the development cycle has gone. I've attempted this several times, however it's hard to measure and it's difficult to truly estimate, especially in an organization that forces developers to work on several projects at once. 

Thoughts? I already think that Agile only works for dedicated teams and not ones that have to share team members. Am I right? 

aver406</description>
		<content:encoded><![CDATA[<p>Mishkin:<br />
One question that comes up as a Project manager is &#8220;how do you measure completeness&#8221; with Agile? So often MS Project can&#8217;t accurately reflect how far along the development cycle has gone. I&#8217;ve attempted this several times, however it&#8217;s hard to measure and it&#8217;s difficult to truly estimate, especially in an organization that forces developers to work on several projects at once. </p>
<p>Thoughts? I already think that Agile only works for dedicated teams and not ones that have to share team members. Am I right? </p>
<p>aver406</p>
]]></content:encoded>
	</item>
</channel>
</rss>
