<?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: Scrum Tips: Managing Task Items</title>
	<atom:link href="http://www.michaelhamrah.com/blog/2009/03/scrum-tips-managing-task-items/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.michaelhamrah.com/blog/2009/03/scrum-tips-managing-task-items/</link>
	<description>All the stuff after "Hello, World!"</description>
	<lastBuildDate>Thu, 02 Sep 2010 15:57:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Michael</title>
		<link>http://www.michaelhamrah.com/blog/2009/03/scrum-tips-managing-task-items/comment-page-1/#comment-88</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Tue, 17 Mar 2009 02:00:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.michaelhamrah.com/blog/?p=201#comment-88</guid>
		<description>Hey Robert- thanks for the comment.  I agree it&#039;s pretty impossible to apply the same item rule to every backlog item all the time.  It&#039;s really up to the discretion of the scrum master to determine what makes sense (Yes, task distribution goes against scrum methodology; but it&#039;s important to do when getting started).  I do believe that more often than not tasks can be distributed across the entire team if they&#039;re analyzed correctly- try as best you can to work in parallel.  It doesn&#039;t always make sense; but here&#039;s some things you can try:

1) On a six person team with lots of little items I&#039;d suggest breaking down into two teams of three people and have each team pull items in priority order off the same backlog.   
2) For medium or small items which are distributed across layers each developer can take a layer, even if it&#039;s just one function or method change.
3) Have developers not actively developing take on some QA or code analysis work (Oh, the horror!)
4) Team up for xp pair programming.
5) Leverage unused dev cycles for backlog items for refactoring or code cleanup efforts related to the item.

Also, don&#039;t settle for a simple &quot;Yes&quot; answer to &quot;Is this done?&quot;.  Follow up with &quot;Can it be released?&quot;, &quot;Would you put money on it?&quot;, &quot;Would you bet your life (or job) on it?&quot;, &quot;Is it everything you wanted it be and then some?&quot;.  You&#039;d be surprised what happens when you throw a lot of resources on small problems- it&#039;s a solid investment for a quality deliverable.

The main idea is don&#039;t leave items in the hands of one person- leverage the group to solve problems collectively (unless, of course, the item is a no brainer).</description>
		<content:encoded><![CDATA[<p>Hey Robert- thanks for the comment.  I agree it&#8217;s pretty impossible to apply the same item rule to every backlog item all the time.  It&#8217;s really up to the discretion of the scrum master to determine what makes sense (Yes, task distribution goes against scrum methodology; but it&#8217;s important to do when getting started).  I do believe that more often than not tasks can be distributed across the entire team if they&#8217;re analyzed correctly- try as best you can to work in parallel.  It doesn&#8217;t always make sense; but here&#8217;s some things you can try:</p>
<p>1) On a six person team with lots of little items I&#8217;d suggest breaking down into two teams of three people and have each team pull items in priority order off the same backlog.<br />
2) For medium or small items which are distributed across layers each developer can take a layer, even if it&#8217;s just one function or method change.<br />
3) Have developers not actively developing take on some QA or code analysis work (Oh, the horror!)<br />
4) Team up for xp pair programming.<br />
5) Leverage unused dev cycles for backlog items for refactoring or code cleanup efforts related to the item.</p>
<p>Also, don&#8217;t settle for a simple &#8220;Yes&#8221; answer to &#8220;Is this done?&#8221;.  Follow up with &#8220;Can it be released?&#8221;, &#8220;Would you put money on it?&#8221;, &#8220;Would you bet your life (or job) on it?&#8221;, &#8220;Is it everything you wanted it be and then some?&#8221;.  You&#8217;d be surprised what happens when you throw a lot of resources on small problems- it&#8217;s a solid investment for a quality deliverable.</p>
<p>The main idea is don&#8217;t leave items in the hands of one person- leverage the group to solve problems collectively (unless, of course, the item is a no brainer).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RobertL</title>
		<link>http://www.michaelhamrah.com/blog/2009/03/scrum-tips-managing-task-items/comment-page-1/#comment-87</link>
		<dc:creator>RobertL</dc:creator>
		<pubDate>Mon, 16 Mar 2009 16:11:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.michaelhamrah.com/blog/?p=201#comment-87</guid>
		<description>In practice, I&#039;ve never seen rule 1 (All developers should work on the same backlog item) consistently used. I&#039;ve spoken with many scrummasters and none, zero, of them have seen a team faithfully apply this. Maybe occasionally if the backlog item is large. Some backlog items are simply too small for a, for example, 6 person team to work on. At a recent Agile Atlanta usergroup meeting I spoke with a guy who teaches scrum and coaches agile teams who said that, in practice, he&#039;s never seen this happen except with small scrum teams and a large backlog item. In practice, do you really see this happen? With all backlog items?</description>
		<content:encoded><![CDATA[<p>In practice, I&#8217;ve never seen rule 1 (All developers should work on the same backlog item) consistently used. I&#8217;ve spoken with many scrummasters and none, zero, of them have seen a team faithfully apply this. Maybe occasionally if the backlog item is large. Some backlog items are simply too small for a, for example, 6 person team to work on. At a recent Agile Atlanta usergroup meeting I spoke with a guy who teaches scrum and coaches agile teams who said that, in practice, he&#8217;s never seen this happen except with small scrum teams and a large backlog item. In practice, do you really see this happen? With all backlog items?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
