<?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: There&#8217;s a Problem with Burndown Charts</title>
	<atom:link href="http://brainslink.com/2012/08/theres-a-problem-with-burndown-charts/feed/" rel="self" type="application/rss+xml" />
	<link>http://brainslink.com/2012/08/theres-a-problem-with-burndown-charts/</link>
	<description></description>
	<lastBuildDate>Mon, 17 Jun 2013 10:26:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Vin</title>
		<link>http://brainslink.com/2012/08/theres-a-problem-with-burndown-charts/comment-page-1/#comment-2301</link>
		<dc:creator>Vin</dc:creator>
		<pubDate>Tue, 12 Mar 2013 00:07:50 +0000</pubDate>
		<guid isPermaLink="false">http://brainslink.com/?p=1814#comment-2301</guid>
		<description><![CDATA[Excellent points, Devin. It seems that burndown charts have different meanings among software development teams. Any tool is only as good as the person using it. Any tool should also have a clear purpose. Simply drawing a burndown chart because it is a recommended practice isn&#039;t good enough. I think the potential for misuse is great. I just don&#039;t like them.]]></description>
		<content:encoded><![CDATA[<p>Excellent points, Devin. It seems that burndown charts have different meanings among software development teams. Any tool is only as good as the person using it. Any tool should also have a clear purpose. Simply drawing a burndown chart because it is a recommended practice isn&#8217;t good enough. I think the potential for misuse is great. I just don&#8217;t like them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Devin Hedge</title>
		<link>http://brainslink.com/2012/08/theres-a-problem-with-burndown-charts/comment-page-1/#comment-2298</link>
		<dc:creator>Devin Hedge</dc:creator>
		<pubDate>Mon, 11 Mar 2013 22:36:10 +0000</pubDate>
		<guid isPermaLink="false">http://brainslink.com/?p=1814#comment-2298</guid>
		<description><![CDATA[I just ran across this post. I&#039;m surprised no &quot;Agile fan boys&quot; jumped on you. I can see what you are talking about; however, I think there are two counter arguments for burndown charts that I would ask you to consider.

Assumptions:

1. The story points for a release should be fixed based on the teams capacity in story points if there is a fixed release date.


2. As scope changes, given a fixed time and fixed cost, items as the bottom of the release backlog should fall off the release backlog. Ken and Jeff are advocating just one backlog, the product backlog. That&#039;s fair and I see their point, but by keeping separate backlogs for each of the levels of planning, I can keep items that slip out of scope somewhere and still only focus on what is in scope.

So, maybe it&#039;s not so much that the release burndown chart isn&#039;t conveying everything you need it to. Most of the electronic tools I&#039;ve seen stink at this. Things I&#039;d want to see are planned, and forcasted (based on a three-iteration running average velocity) zero-crossing points on the burndown. I&#039;d also like the chart to burndown from the planned capacity and then it recaculate over time with a scope line.

Without these crucial elements, you are correct, it isn&#039;t that useful of a project management device.]]></description>
		<content:encoded><![CDATA[<p>I just ran across this post. I&#8217;m surprised no &#8220;Agile fan boys&#8221; jumped on you. I can see what you are talking about; however, I think there are two counter arguments for burndown charts that I would ask you to consider.</p>
<p>Assumptions:</p>
<p>1. The story points for a release should be fixed based on the teams capacity in story points if there is a fixed release date.</p>
<p>2. As scope changes, given a fixed time and fixed cost, items as the bottom of the release backlog should fall off the release backlog. Ken and Jeff are advocating just one backlog, the product backlog. That&#8217;s fair and I see their point, but by keeping separate backlogs for each of the levels of planning, I can keep items that slip out of scope somewhere and still only focus on what is in scope.</p>
<p>So, maybe it&#8217;s not so much that the release burndown chart isn&#8217;t conveying everything you need it to. Most of the electronic tools I&#8217;ve seen stink at this. Things I&#8217;d want to see are planned, and forcasted (based on a three-iteration running average velocity) zero-crossing points on the burndown. I&#8217;d also like the chart to burndown from the planned capacity and then it recaculate over time with a scope line.</p>
<p>Without these crucial elements, you are correct, it isn&#8217;t that useful of a project management device.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
