<?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: Stories and Capabilities</title>
	<atom:link href="http://iansrobinson.com/2008/10/28/stories-and-capabilities/feed/" rel="self" type="application/rss+xml" />
	<link>http://iansrobinson.com/2008/10/28/stories-and-capabilities/</link>
	<description>Ian Robinson&#039;s Blog</description>
	<lastBuildDate>Mon, 06 Sep 2010 07:27:36 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Colin Jack</title>
		<link>http://iansrobinson.com/2008/10/28/stories-and-capabilities/comment-page-1/#comment-46</link>
		<dc:creator>Colin Jack</dc:creator>
		<pubDate>Wed, 12 Nov 2008 13:25:34 +0000</pubDate>
		<guid isPermaLink="false">http://iansrobinson.com/?p=26#comment-46</guid>
		<description>I can see you have a very valid point, but still I can&#039;t help wondering whether the problems Martin Fowler and Dan North describe are not down to misuse of stories.

When I think of user stories I think of starting with epics, then breaking them down into stories for the next couple of iterations, then breaking stories for current iteration down to get details (acceptance criteria, examples etc). Different people might be involved in each step.

If you do things that way I think your less at risk of losing the goals. Mind you I can see that the goals are often missing from the story cards and are left implicit but you do have the conversations which should cover the goals that motivate the story (business value, priority etc).

Just reading on to where you describe using stories/capabilities at high-level capability workshops, could you not view the outputs of these as epics? If you do then these epics could spawn one or more estimatable/testable stories, thats an approach I&#039;ve used before and liked even if its not really discussed in the user story literature. Still doesn&#039;t necessarily make the goal as explicit as it could be though I guess.</description>
		<content:encoded><![CDATA[<p>I can see you have a very valid point, but still I can&#8217;t help wondering whether the problems Martin Fowler and Dan North describe are not down to misuse of stories.</p>
<p>When I think of user stories I think of starting with epics, then breaking them down into stories for the next couple of iterations, then breaking stories for current iteration down to get details (acceptance criteria, examples etc). Different people might be involved in each step.</p>
<p>If you do things that way I think your less at risk of losing the goals. Mind you I can see that the goals are often missing from the story cards and are left implicit but you do have the conversations which should cover the goals that motivate the story (business value, priority etc).</p>
<p>Just reading on to where you describe using stories/capabilities at high-level capability workshops, could you not view the outputs of these as epics? If you do then these epics could spawn one or more estimatable/testable stories, thats an approach I&#8217;ve used before and liked even if its not really discussed in the user story literature. Still doesn&#8217;t necessarily make the goal as explicit as it could be though I guess.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
