<?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: Velocity planning or capacity planning (or both)?</title>
	<atom:link href="http://www.borselaer.org/index.php/2009/06/velocity-planning-or-capacity-planning-or-both/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.borselaer.org/index.php/2009/06/velocity-planning-or-capacity-planning-or-both/</link>
	<description>Thoughts on agile project management based on human values and behavior and using PRINCE2, Scrum and Lean principles.</description>
	<lastBuildDate>Mon, 28 Nov 2011 14:36:01 +0100</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Deborah Hartmann Preuss</title>
		<link>http://www.borselaer.org/index.php/2009/06/velocity-planning-or-capacity-planning-or-both/comment-page-1/#comment-2326</link>
		<dc:creator>Deborah Hartmann Preuss</dc:creator>
		<pubDate>Tue, 07 Sep 2010 05:59:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.borselaer.org/?p=160#comment-2326</guid>
		<description>You are right about capacity: in fact every team member should come to planning with data about his capacity for the next sprint - planned vacation, training, etc. 

However, requiring developers to record actual hours spent seems like overkill. Why not calculate sprint capacity in story points? If you know a point = half a day, and Joe will be absent one day, remove 2 story points from team&#039;s regular sprint capacity and you are done. 

There is a reason we usually don&#039;t mix real hours and story points in this way: simplicity. Many have found that the simpler way works &quot;well enough&quot; that the team can stop reporting actuals. What is more important than actuals is estimates and learning to estimate better, and they get this from standups and burndown. You might try it to see if it works well enough, and retrospect it after three sprints!

Have fun!
deb</description>
		<content:encoded><![CDATA[<p>You are right about capacity: in fact every team member should come to planning with data about his capacity for the next sprint &#8211; planned vacation, training, etc. </p>
<p>However, requiring developers to record actual hours spent seems like overkill. Why not calculate sprint capacity in story points? If you know a point = half a day, and Joe will be absent one day, remove 2 story points from team&#8217;s regular sprint capacity and you are done. </p>
<p>There is a reason we usually don&#8217;t mix real hours and story points in this way: simplicity. Many have found that the simpler way works &#8220;well enough&#8221; that the team can stop reporting actuals. What is more important than actuals is estimates and learning to estimate better, and they get this from standups and burndown. You might try it to see if it works well enough, and retrospect it after three sprints!</p>
<p>Have fun!<br />
deb</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Calculating Capacity of an Agile Team « mikkeman.nl</title>
		<link>http://www.borselaer.org/index.php/2009/06/velocity-planning-or-capacity-planning-or-both/comment-page-1/#comment-29</link>
		<dc:creator>Calculating Capacity of an Agile Team « mikkeman.nl</dc:creator>
		<pubDate>Mon, 02 Nov 2009 11:21:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.borselaer.org/?p=160#comment-29</guid>
		<description>[...] composition, no holidays, no illness, no sudden fires to put out, etc..etc.. I while ago I read this post from my colleague Martin van Borselaer. In that post he proposes [...]</description>
		<content:encoded><![CDATA[<p>[...] composition, no holidays, no illness, no sudden fires to put out, etc..etc.. I while ago I read this post from my colleague Martin van Borselaer. In that post he proposes [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

