<?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: Brainstorming &#8211; Making Something Out of Everything</title>
	<atom:link href="http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/</link>
	<description>Software product success.</description>
	<lastBuildDate>Thu, 18 Mar 2010 20:39:50 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ten Requirements Gathering Techniques &#171; Little K&#8217;s Blog</title>
		<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/comment-page-1/#comment-57197</link>
		<dc:creator>Ten Requirements Gathering Techniques &#171; Little K&#8217;s Blog</dc:creator>
		<pubDate>Thu, 23 Nov 2006 05:13:19 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comment-57197</guid>
		<description>[...] Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack. [...]</description>
		<content:encoded><![CDATA[<p>[...] Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/comment-page-1/#comment-179</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Tue, 31 Jan 2006 18:32:59 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comment-179</guid>
		<description>Hey Roger,

Great point about using &#039;problem&#039; instead of &#039;requirement&#039; - &#039;opportunity&#039; also works, imho.</description>
		<content:encoded><![CDATA[<p>Hey Roger,</p>
<p>Great point about using &#8216;problem&#8217; instead of &#8216;requirement&#8217; &#8211; &#8216;opportunity&#8217; also works, imho.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roger L. Cauvin</title>
		<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/comment-page-1/#comment-108</link>
		<dc:creator>Roger L. Cauvin</dc:creator>
		<pubDate>Thu, 19 Jan 2006 16:16:16 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comment-108</guid>
		<description>I like the use of brainstorming as a technique for eliciting requirements, and I think you do a good job of describing an effective brainstorming process.

In the context of requirements elicitation, I would add that the way you frame the &quot;ground rules&quot; is critical.  When I elicit requirements, I generally don&#039;t even use the word &quot;requirement&quot; in the discussion.  Not only is the term fraught with misunderstanding (as I frequently and relentlessly point out in my blog and other forums), but the word itself really isn&#039;t very important.

A requirements brainstorming session should really be a &lt;i&gt;problem&lt;/i&gt; brainstorming session.  Who are the interested stakeholders?  What problems should the product solve or help these stakeholders avoid?  After the brainstorming session, you can elaborate on these problems, come up with metrics that state what it would mean to solve or avoid them, and negotiate what is feasible to implement.  It&#039;s the metrics that are the requirements.</description>
		<content:encoded><![CDATA[<p>I like the use of brainstorming as a technique for eliciting requirements, and I think you do a good job of describing an effective brainstorming process.</p>
<p>In the context of requirements elicitation, I would add that the way you frame the &#8220;ground rules&#8221; is critical.  When I elicit requirements, I generally don&#8217;t even use the word &#8220;requirement&#8221; in the discussion.  Not only is the term fraught with misunderstanding (as I frequently and relentlessly point out in my blog and other forums), but the word itself really isn&#8217;t very important.</p>
<p>A requirements brainstorming session should really be a <i>problem</i> brainstorming session.  Who are the interested stakeholders?  What problems should the product solve or help these stakeholders avoid?  After the brainstorming session, you can elaborate on these problems, come up with metrics that state what it would mean to solve or avoid them, and negotiate what is feasible to implement.  It&#8217;s the metrics that are the requirements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Prioritizing requirements - three techniques</title>
		<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/comment-page-1/#comment-103</link>
		<dc:creator>Tyner Blain &#187; Prioritizing requirements - three techniques</dc:creator>
		<pubDate>Thu, 19 Jan 2006 05:02:04 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comment-103</guid>
		<description>[...] We can try to avoid this problem and force an even distribution of high, medium and low requirements. A simple approach, and we used it when we are facilitating a brainstorming session. This works great when we&#8217;re working in the abstract, or prioritizing brand new ideas as a starting point for future discussions. However, when truly prioritizing requirements, we run into people who think everything is critically important. Try to force these people into three equally sized buckets and they will revolt. Without careful prompting, I&#8217;ve never seen a session result in fewer than half of the &#8220;real&#8221; features (or bugs) in the high priority bucket. We can learn something from the french fries here. While marketing may put names like &#8220;value sized&#8221; and &#8220;eat this and it&#8217;s free&#8221; on the different sizes, the bottom line is that there is one size which is the smallest, one size which is the largest, and one size which is in the middle. It&#8217;s all relative. The same is true with requirements, so&#8230; [...]</description>
		<content:encoded><![CDATA[<p>[...] We can try to avoid this problem and force an even distribution of high, medium and low requirements. A simple approach, and we used it when we are facilitating a brainstorming session. This works great when we&#8217;re working in the abstract, or prioritizing brand new ideas as a starting point for future discussions. However, when truly prioritizing requirements, we run into people who think everything is critically important. Try to force these people into three equally sized buckets and they will revolt. Without careful prompting, I&#8217;ve never seen a session result in fewer than half of the &#8220;real&#8221; features (or bugs) in the high priority bucket. We can learn something from the french fries here. While marketing may put names like &#8220;value sized&#8221; and &#8220;eat this and it&#8217;s free&#8221; on the different sizes, the bottom line is that there is one size which is the smallest, one size which is the largest, and one size which is in the middle. It&#8217;s all relative. The same is true with requirements, so&#8230; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Top five requirements gathering tips</title>
		<link>http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/comment-page-1/#comment-100</link>
		<dc:creator>Tyner Blain &#187; Top five requirements gathering tips</dc:creator>
		<pubDate>Wed, 18 Jan 2006 04:40:42 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comment-100</guid>
		<description>[...] Brainstorming. Brainstorming is a very effective technique for idea generation. Brainstorming is most effective when there are two phases - creating ideas and validating ideas. The key to making brainstorming work is to not criticize, remove, or prioritize any ideas during the creation phase. A bad idea may lead to a brilliant one, but if people discount it, it won&#8217;t lead anywhere. After we are done creating ideas, we can move into the validation phase, where bad ideas are removed and good ideas are prioritized. Concept maps provide a great way to organize ideas as they are being prioritized.  Here&#8217;s a post on how to use brainstorming for requirements gathering. [...]</description>
		<content:encoded><![CDATA[<p>[...] Brainstorming. Brainstorming is a very effective technique for idea generation. Brainstorming is most effective when there are two phases &#8211; creating ideas and validating ideas. The key to making brainstorming work is to not criticize, remove, or prioritize any ideas during the creation phase. A bad idea may lead to a brilliant one, but if people discount it, it won&#8217;t lead anywhere. After we are done creating ideas, we can move into the validation phase, where bad ideas are removed and good ideas are prioritized. Concept maps provide a great way to organize ideas as they are being prioritized.  Here&#8217;s a post on how to use brainstorming for requirements gathering. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
