<?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: WEBINAR &#8211; Effective Specifications for Agile Projects</title>
	<atom:link href="http://www.AgilistaPM.com/effective-specifications/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.AgilistaPM.com/effective-specifications/</link>
	<description></description>
	<lastBuildDate>Tue, 16 Nov 2010 10:06:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Gojko Adzic</title>
		<link>http://www.AgilistaPM.com/effective-specifications/comment-page-1/#comment-436</link>
		<dc:creator>Gojko Adzic</dc:creator>
		<pubDate>Thu, 26 Aug 2010 14:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.AgilistaPM.com/?p=3734#comment-436</guid>
		<description>Huet,

I wouldn&#039;t say that &quot;most Agile teams appear to be doing a good job&quot; simply because I have no data to clam that or otherwise. From my experience, quite a few teams labeling themselves agile actually don&#039;t do this properly. The webinar was my attempt to raise awareness about these good practices. I agree with you that test-driven approach, reducing backlog size etc  are good ways to do that and I hope that came through in the webinar.

I&#039;ve used effect maps to provide a global overview of a milestone. Depending on how good the team is with slicing MMFs, level four of the map could be high-level features (&quot;epics&quot;) or stories themselves. Once the team has capacity to accept more items into the backlog, a map will give the business stakeholders an idea what to focus on next and which areas of the map need to be expanded. User stories typically come from level 4 or level 5 on the map. Sometimes we had these detailed on the map in advance, sometimes we would decide that it&#039;s time to put more details into the map from the fourth level down when the time comes to implement a particular feature. At that point we&#039;d get the stories from the map and put them into the backlog. This keeps the backlog relatively thin all the time.</description>
		<content:encoded><![CDATA[<p>Huet,</p>
<p>I wouldn&#8217;t say that &#8220;most Agile teams appear to be doing a good job&#8221; simply because I have no data to clam that or otherwise. From my experience, quite a few teams labeling themselves agile actually don&#8217;t do this properly. The webinar was my attempt to raise awareness about these good practices. I agree with you that test-driven approach, reducing backlog size etc  are good ways to do that and I hope that came through in the webinar.</p>
<p>I&#8217;ve used effect maps to provide a global overview of a milestone. Depending on how good the team is with slicing MMFs, level four of the map could be high-level features (&#8220;epics&#8221;) or stories themselves. Once the team has capacity to accept more items into the backlog, a map will give the business stakeholders an idea what to focus on next and which areas of the map need to be expanded. User stories typically come from level 4 or level 5 on the map. Sometimes we had these detailed on the map in advance, sometimes we would decide that it&#8217;s time to put more details into the map from the fourth level down when the time comes to implement a particular feature. At that point we&#8217;d get the stories from the map and put them into the backlog. This keeps the backlog relatively thin all the time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Huet Landry</title>
		<link>http://www.AgilistaPM.com/effective-specifications/comment-page-1/#comment-429</link>
		<dc:creator>Huet Landry</dc:creator>
		<pubDate>Wed, 18 Aug 2010 16:54:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.AgilistaPM.com/?p=3734#comment-429</guid>
		<description>Gojko,

I find that your statements about the problems associated with software development seem to differ somewhat with the most common problems that I have seen discussed in Agile forums.  Many of the problems that you mention were the cause for many teams to begin moving from waterfall to iterative or Agile approaches.  For example, most Agile teams appear to be doing a good job of matching the tests to user stories - many use a test-driven-development approach where the user stories to be implemented are in fact, the tests.  Many Agile teams are moving towards minimizing their Product Backlogs (e.g. the kanban approach), so they would not necessarily be interested in maintaining large effect trees.

Despite this, I believe that the Effect Maps are a good answer to the problematic practice of not retaining &quot;epic&quot; stories in XP and Scrum.  I have found that retaining the heirarchy if epic stories does exactly what the effect maps do for retaining the history of &quot;why&quot; we choose to implement certain stories in each sprint.

From this presentation, I&#039;m still not exactly sure what items would be brought into a Sprint Planning session in Scrum.</description>
		<content:encoded><![CDATA[<p>Gojko,</p>
<p>I find that your statements about the problems associated with software development seem to differ somewhat with the most common problems that I have seen discussed in Agile forums.  Many of the problems that you mention were the cause for many teams to begin moving from waterfall to iterative or Agile approaches.  For example, most Agile teams appear to be doing a good job of matching the tests to user stories &#8211; many use a test-driven-development approach where the user stories to be implemented are in fact, the tests.  Many Agile teams are moving towards minimizing their Product Backlogs (e.g. the kanban approach), so they would not necessarily be interested in maintaining large effect trees.</p>
<p>Despite this, I believe that the Effect Maps are a good answer to the problematic practice of not retaining &#8220;epic&#8221; stories in XP and Scrum.  I have found that retaining the heirarchy if epic stories does exactly what the effect maps do for retaining the history of &#8220;why&#8221; we choose to implement certain stories in each sprint.</p>
<p>From this presentation, I&#8217;m still not exactly sure what items would be brought into a Sprint Planning session in Scrum.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

