<?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: I Don&#8217;t Like MoSCoW</title>
	<atom:link href="http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/</link>
	<description>Adopt, Scale and Succeed with Agile Development</description>
	<lastBuildDate>Wed, 28 Jul 2010 21:21:14 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ken Clyne</title>
		<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/#comment-3548</link>
		<dc:creator>Ken Clyne</dc:creator>
		<pubDate>Mon, 06 Jul 2009 17:47:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2322#comment-3548</guid>
		<description>Thanks for all the comments. I&#039;m encouraged to hear that everyone responding has a pragmatic approach to the technique.

Almost every email I got on an Atern roadshow mentions MoSCoW prioritisation and I was curious to find out how integral it is to DSDM.</description>
		<content:encoded><![CDATA[<p>Thanks for all the comments. I&#8217;m encouraged to hear that everyone responding has a pragmatic approach to the technique.</p>
<p>Almost every email I got on an Atern roadshow mentions MoSCoW prioritisation and I was curious to find out how integral it is to DSDM.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Jackson</title>
		<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/#comment-3543</link>
		<dc:creator>Paul Jackson</dc:creator>
		<pubDate>Fri, 03 Jul 2009 08:28:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2322#comment-3543</guid>
		<description>I agree with all the excellent comments here. I use MoSCoW during the first sweep prioritisation so we have a high-level understanding of what&#039;s important to the client - and I have to admit that I&#039;ve hardly seen any features in the &quot;Won&#039;t Have&quot; bucket!
But then I use this output and drill down into more detailed analysis with the client, so that they score each feature based on the benefit to the business of building it and the impact of leaving it out.  Then I get the techies involved to get some stats on how easy or difficult it will be to develop, whether they can re-use previous code or it&#039;s cutting-edge technology.  We also weight some of the features depending on critical (business) importance.  This normally provides a more detailed prioritistion for the Product Backlog; but then we sit down with the client so they can apply some business judgement to the scoring.  It doesn&#039;t work every time but it helps us kick off the first Sprint and gets the client thinking about what &quot;really&quot; is their priority.</description>
		<content:encoded><![CDATA[<p>I agree with all the excellent comments here. I use MoSCoW during the first sweep prioritisation so we have a high-level understanding of what&#8217;s important to the client &#8211; and I have to admit that I&#8217;ve hardly seen any features in the &#8220;Won&#8217;t Have&#8221; bucket!<br />
But then I use this output and drill down into more detailed analysis with the client, so that they score each feature based on the benefit to the business of building it and the impact of leaving it out.  Then I get the techies involved to get some stats on how easy or difficult it will be to develop, whether they can re-use previous code or it&#8217;s cutting-edge technology.  We also weight some of the features depending on critical (business) importance.  This normally provides a more detailed prioritistion for the Product Backlog; but then we sit down with the client so they can apply some business judgement to the scoring.  It doesn&#8217;t work every time but it helps us kick off the first Sprint and gets the client thinking about what &#8220;really&#8221; is their priority.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean Tabaka</title>
		<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/#comment-3446</link>
		<dc:creator>Jean Tabaka</dc:creator>
		<pubDate>Mon, 08 Jun 2009 19:30:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2322#comment-3446</guid>
		<description>Thanks for the article Ken. You really bring up some good information about MoSCOW abuse. 

My first exposure to Agile was through DSDM. So, I have to admit I have something of a pre-disposed likeness for MoSCoW. It was a great way to do the pre-sorting mentioned above.  I think of it as a garage sale, where there is agreement about how many items can be MUST HAVEs. And, I use the &quot;W&quot; sort of like the bottom of a Product Backlog. The product owner &quot;WOULD&quot; get them if the backlog weren&#039;t so big and they didn&#039;t have so many higher priority items and didn&#039;t keep adding more.

The idea of using them in a silent grouping for initial buckets can help a team stand back and see the truth of initial impressions about the &quot;MUST HAVES&quot;. Wow! We have a lot. Are you now prepared to rank them, product owner? Do you really want us to now size allllll of these before we start to give you commitments?? Having that bucket visual can be a real eye-opener. And it can be a nice way to jumpstart the ranking for those cantankerous product owners who first refuse to.

Anyway, just some ideas about how to NOT let MoSCoW abuse continue! Thanks for bringing this up. The only way to address a problem is to first admit you have one. I think that is definitely true about MoSCoW (ab)use :- )

Jean</description>
		<content:encoded><![CDATA[<p>Thanks for the article Ken. You really bring up some good information about MoSCOW abuse. </p>
<p>My first exposure to Agile was through DSDM. So, I have to admit I have something of a pre-disposed likeness for MoSCoW. It was a great way to do the pre-sorting mentioned above.  I think of it as a garage sale, where there is agreement about how many items can be MUST HAVEs. And, I use the &#8220;W&#8221; sort of like the bottom of a Product Backlog. The product owner &#8220;WOULD&#8221; get them if the backlog weren&#8217;t so big and they didn&#8217;t have so many higher priority items and didn&#8217;t keep adding more.</p>
<p>The idea of using them in a silent grouping for initial buckets can help a team stand back and see the truth of initial impressions about the &#8220;MUST HAVES&#8221;. Wow! We have a lot. Are you now prepared to rank them, product owner? Do you really want us to now size allllll of these before we start to give you commitments?? Having that bucket visual can be a real eye-opener. And it can be a nice way to jumpstart the ranking for those cantankerous product owners who first refuse to.</p>
<p>Anyway, just some ideas about how to NOT let MoSCoW abuse continue! Thanks for bringing this up. The only way to address a problem is to first admit you have one. I think that is definitely true about MoSCoW (ab)use :- )</p>
<p>Jean</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Duncan</title>
		<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/#comment-3444</link>
		<dc:creator>Scott Duncan</dc:creator>
		<pubDate>Mon, 08 Jun 2009 13:41:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2322#comment-3444</guid>
		<description>I&#039;ve used a MoSCoW-like approach for years before any agile involvement as a &quot;pre-sort&quot; technique (as John Martin suggests) when faced with a lot of requirements.  Then, the 1-n sorting goes on within each category.

I, too, have always found the &quot;Won&#039;t Have&quot; category to not be very useful.  I know it&#039;s supposed to be where things go that, after reflection, won&#039;t be part of the current delivery plans.  But the &quot;Could Have&quot; category is close in meaning as it represents things that can be left out (of the current increment).  Of course, the Could Have description refers to &quot;the current increment&quot; while the Won&#039;t Have refers to &quot;the current delivery&quot; which is, presumably, made up of numerous increments.

But it is how the categories get used and how granular the approach is in making distinctions between items that would be the key for determining what goes into a specific iteration.  At that level, buckets, with otherwise unordered contents, can produce the issues the people in classes note.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve used a MoSCoW-like approach for years before any agile involvement as a &#8220;pre-sort&#8221; technique (as John Martin suggests) when faced with a lot of requirements.  Then, the 1-n sorting goes on within each category.</p>
<p>I, too, have always found the &#8220;Won&#8217;t Have&#8221; category to not be very useful.  I know it&#8217;s supposed to be where things go that, after reflection, won&#8217;t be part of the current delivery plans.  But the &#8220;Could Have&#8221; category is close in meaning as it represents things that can be left out (of the current increment).  Of course, the Could Have description refers to &#8220;the current increment&#8221; while the Won&#8217;t Have refers to &#8220;the current delivery&#8221; which is, presumably, made up of numerous increments.</p>
<p>But it is how the categories get used and how granular the approach is in making distinctions between items that would be the key for determining what goes into a specific iteration.  At that level, buckets, with otherwise unordered contents, can produce the issues the people in classes note.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Martin</title>
		<link>http://www.rallydev.com/agileblog/2009/06/i-dont-like-moscow/#comment-3424</link>
		<dc:creator>John Martin</dc:creator>
		<pubDate>Fri, 05 Jun 2009 20:07:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2322#comment-3424</guid>
		<description>I have to admit I&#039;ve never understood the point of Won&#039;t Have.  

I think that MoSCoW should be used as a first-level sorter, followed by the individual sorting.  If you can get them to stop thinking everything is #1 and only 1/4 of the things are #1 (all the musts), you&#039;ve made some progress, don&#039;t you think?  Then they can concentrate on making sure they&#039;re clearest on what they mean by the stories in the must category so that we spend our time estimating those instead of things that might wind up with Ws.

That is, I see MoSCoW sorting as useful _before_ estimation.

In your situation #2, I&#039;d say you either wait (because you had their commitment to be a part of the team, right? :) ) or you pick the one that fits the theme or has technical advantages.  He/she is giving the team some autonomy there, right?</description>
		<content:encoded><![CDATA[<p>I have to admit I&#8217;ve never understood the point of Won&#8217;t Have.  </p>
<p>I think that MoSCoW should be used as a first-level sorter, followed by the individual sorting.  If you can get them to stop thinking everything is #1 and only 1/4 of the things are #1 (all the musts), you&#8217;ve made some progress, don&#8217;t you think?  Then they can concentrate on making sure they&#8217;re clearest on what they mean by the stories in the must category so that we spend our time estimating those instead of things that might wind up with Ws.</p>
<p>That is, I see MoSCoW sorting as useful _before_ estimation.</p>
<p>In your situation #2, I&#8217;d say you either wait (because you had their commitment to be a part of the team, right? :) ) or you pick the one that fits the theme or has technical advantages.  He/she is giving the team some autonomy there, right?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
