<?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: Defining the scope of an epic before listing user stories in an agile product backlog</title>
	<atom:link href="http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/</link>
	<description>Helping business analysts become leaders and advance their careers.</description>
	<lastBuildDate>Fri, 12 Mar 2010 17:33:53 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Anish Cheriyan</title>
		<link>http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/comment-page-1/#comment-4797</link>
		<dc:creator>Anish Cheriyan</dc:creator>
		<pubDate>Sun, 07 Mar 2010 00:27:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=750#comment-4797</guid>
		<description>Hi Laura,
Thanks for the article. It is quite good from the Epic perspective.
Some of the aspects which I feel the Agile Community needs to further work is how story card can be sliced vertically well in respective domain. I feel we need to address this from a domain perspective like application domain, emedded system domain, protocol based development etc. 

Regards
Anish


Because based on this the detailing of the story card may change.</description>
		<content:encoded><![CDATA[<p>Hi Laura,<br />
Thanks for the article. It is quite good from the Epic perspective.<br />
Some of the aspects which I feel the Agile Community needs to further work is how story card can be sliced vertically well in respective domain. I feel we need to address this from a domain perspective like application domain, emedded system domain, protocol based development etc. </p>
<p>Regards<br />
Anish</p>
<p>Because based on this the detailing of the story card may change.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura (Brandau) Brandenburg</title>
		<link>http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/comment-page-1/#comment-3795</link>
		<dc:creator>Laura (Brandau) Brandenburg</dc:creator>
		<pubDate>Tue, 10 Nov 2009 14:34:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=750#comment-3795</guid>
		<description>Jodi, I am glad you found this helpful. It&#039;s so easy to throw out what has helped us in the past when learning a new process.

Anmol, In my situation the Product Owner also called the shots about what epics and user stories needed to exist. In my BA role, I had a piece of the product owner role as well. So I was the one driving the elaboration of the epics and stories and helping the Product Owner keep them prioritized. The BA is not always in this role, as your experience shows, but it was a good partnership on this particular team.

There is a lot out there on agile for distributed teams. In my case, even though the business and development teams are in the same city, they are in different offices. This leads to more overhead in terms of documentation and less face-to-face communication. There are some drawbacks if you compare your situation against the &quot;ideal&quot;, but I would challenge you to evaluate the alternatives. Would a BRD work any better or cause more problems? I do sympathize with the timing issues and that seems to be a common issue amongst distributed teams.

Laura</description>
		<content:encoded><![CDATA[<p>Jodi, I am glad you found this helpful. It&#8217;s so easy to throw out what has helped us in the past when learning a new process.</p>
<p>Anmol, In my situation the Product Owner also called the shots about what epics and user stories needed to exist. In my BA role, I had a piece of the product owner role as well. So I was the one driving the elaboration of the epics and stories and helping the Product Owner keep them prioritized. The BA is not always in this role, as your experience shows, but it was a good partnership on this particular team.</p>
<p>There is a lot out there on agile for distributed teams. In my case, even though the business and development teams are in the same city, they are in different offices. This leads to more overhead in terms of documentation and less face-to-face communication. There are some drawbacks if you compare your situation against the &#8220;ideal&#8221;, but I would challenge you to evaluate the alternatives. Would a BRD work any better or cause more problems? I do sympathize with the timing issues and that seems to be a common issue amongst distributed teams.</p>
<p>Laura</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anmol</title>
		<link>http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/comment-page-1/#comment-3793</link>
		<dc:creator>Anmol</dc:creator>
		<pubDate>Tue, 10 Nov 2009 06:04:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=750#comment-3793</guid>
		<description>I got introduced to the Agile process about 8 monts back. And I can correlate perfectly with your thought on the chalanges faced when one moves from the traditional style BA work (preparing FSD, BRD) to detailing out a user story scope.
Two things that I would like to highlight from my experience is , first- here its mainly the Product Owners who call the shots on what epics&gt; user stories need to exist and they are the ones who priortize these items. Offlate we the BA&#039;s have been given a free hand to elaborate the acceptance criteria the story points. But I think the way you suggested, it would be best if the scoping of a user story is done in consultation with the Dev team, it would save a lot of time and effort.
Second- In my company we work accross geographical region, while the product owners and key decision makers are in USA the dev team and testing team is split accross two centers in India. I feel this has its own major drawback because the very purpose of having agile (flexible/quick/focused) development is beaten. We end up woking late into US working hours and the so called standup meeting or scrum meetings take more time than usual</description>
		<content:encoded><![CDATA[<p>I got introduced to the Agile process about 8 monts back. And I can correlate perfectly with your thought on the chalanges faced when one moves from the traditional style BA work (preparing FSD, BRD) to detailing out a user story scope.<br />
Two things that I would like to highlight from my experience is , first- here its mainly the Product Owners who call the shots on what epics&gt; user stories need to exist and they are the ones who priortize these items. Offlate we the BA&#8217;s have been given a free hand to elaborate the acceptance criteria the story points. But I think the way you suggested, it would be best if the scoping of a user story is done in consultation with the Dev team, it would save a lot of time and effort.<br />
Second- In my company we work accross geographical region, while the product owners and key decision makers are in USA the dev team and testing team is split accross two centers in India. I feel this has its own major drawback because the very purpose of having agile (flexible/quick/focused) development is beaten. We end up woking late into US working hours and the so called standup meeting or scrum meetings take more time than usual</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jodi</title>
		<link>http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/comment-page-1/#comment-961</link>
		<dc:creator>Jodi</dc:creator>
		<pubDate>Thu, 21 May 2009 14:03:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.bridging-the-gap.com/?p=750#comment-961</guid>
		<description>As someone new to Scrum, I am glad to have found your template.  I think it will help me think better about the stories we need to capture.  I especially like that you included a section for Benefits, because we try to ask that question all the time.  Thanks for sharing!</description>
		<content:encoded><![CDATA[<p>As someone new to Scrum, I am glad to have found your template.  I think it will help me think better about the stories we need to capture.  I especially like that you included a section for Benefits, because we try to ask that question all the time.  Thanks for sharing!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
