<?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: The Mythical Customer Problem</title>
	<atom:link href="http://gojko.net/2009/10/01/the-mythical-customer-problem/feed/" rel="self" type="application/rss+xml" />
	<link>http://gojko.net/2009/10/01/the-mythical-customer-problem/</link>
	<description>Building software that matters</description>
	<lastBuildDate>Fri, 18 May 2012 13:40:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: david putman</title>
		<link>http://gojko.net/2009/10/01/the-mythical-customer-problem/comment-page-1/#comment-72683</link>
		<dc:creator>david putman</dc:creator>
		<pubDate>Wed, 27 Jan 2010 08:30:42 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/?p=1139#comment-72683</guid>
		<description>You&#039;ve touched on a very good point here that decisions should indeed be shared and made with input and collaboration from the whole team and as many real customers as possible. 
However, the point of the Customer / Product Owner role is ownership, i.e. who &#039;owns&#039; the decision or, if you like, who takes responsibility for it and has the final say. 
We need to collate a list of stories / tasks in priority order as the backlog for our product / project / release / sprint and we know that when more than one human being is involved there will be a difference of opinion somewhere. To prevent roadblocks we need to decide BEFOREHAND who will have the final say. This is why Scrum mandates the Product Owner role.
Whether it&#039;s someone appointed by the company or members of the team take it turns, the point is that we have one person whose role is to make the decision. Of course, anyone can add an item to the backlog and everyone can and should voice their opinion but ultimately, we should all defer to the Product Owner.
If we feel the Product Owner is inadequate in any way or we have lost respect for them, that is a different issue.</description>
		<content:encoded><![CDATA[<p>You&#8217;ve touched on a very good point here that decisions should indeed be shared and made with input and collaboration from the whole team and as many real customers as possible.<br />
However, the point of the Customer / Product Owner role is ownership, i.e. who &#8216;owns&#8217; the decision or, if you like, who takes responsibility for it and has the final say.<br />
We need to collate a list of stories / tasks in priority order as the backlog for our product / project / release / sprint and we know that when more than one human being is involved there will be a difference of opinion somewhere. To prevent roadblocks we need to decide BEFOREHAND who will have the final say. This is why Scrum mandates the Product Owner role.<br />
Whether it&#8217;s someone appointed by the company or members of the team take it turns, the point is that we have one person whose role is to make the decision. Of course, anyone can add an item to the backlog and everyone can and should voice their opinion but ultimately, we should all defer to the Product Owner.<br />
If we feel the Product Owner is inadequate in any way or we have lost respect for them, that is a different issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Scrimshire</title>
		<link>http://gojko.net/2009/10/01/the-mythical-customer-problem/comment-page-1/#comment-61647</link>
		<dc:creator>James Scrimshire</dc:creator>
		<pubDate>Fri, 02 Oct 2009 08:37:38 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/?p=1139#comment-61647</guid>
		<description>Your description fits with my current client very well. We use customer proxies to talk to the real customers and hold workshops for determining functionality and priority. It would be impossible for us otherwise to get a balanced and comprehensive view of requirements.</description>
		<content:encoded><![CDATA[<p>Your description fits with my current client very well. We use customer proxies to talk to the real customers and hold workshops for determining functionality and priority. It would be impossible for us otherwise to get a balanced and comprehensive view of requirements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Davis</title>
		<link>http://gojko.net/2009/10/01/the-mythical-customer-problem/comment-page-1/#comment-61597</link>
		<dc:creator>Jeff Davis</dc:creator>
		<pubDate>Thu, 01 Oct 2009 15:56:25 +0000</pubDate>
		<guid isPermaLink="false">http://gojko.net/?p=1139#comment-61597</guid>
		<description>I think another common mistake is assuming that the customer knows how best to manage their data. They are sure to know things about the nature of their data, but that doesn&#039;t make them automatically good at managing it for the long term. And there are plenty of hidden customers that have an interest in that data.</description>
		<content:encoded><![CDATA[<p>I think another common mistake is assuming that the customer knows how best to manage their data. They are sure to know things about the nature of their data, but that doesn&#8217;t make them automatically good at managing it for the long term. And there are plenty of hidden customers that have an interest in that data.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

