<?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: What the Hell Is a &#8220;Groomed Backlog&#8221;?</title>
	<atom:link href="http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/</link>
	<description>SolutionsIQ&#039;s Agile thought leaders, thinking out loud</description>
	<lastBuildDate>Mon, 30 Aug 2010 20:43:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: David Koontz</title>
		<link>http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/comment-page-1/#comment-19</link>
		<dc:creator>David Koontz</dc:creator>
		<pubDate>Wed, 04 Mar 2009 23:47:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileiq.org/?p=243#comment-19</guid>
		<description>Oh - I also want to add that we found the most pride in workmanship in the stories that we involved the end-users (or a representative) in the planning and in reviewing the stories as it was being built.  Which allowed for small and medium size changes in the story as the sprint progressed.  These small changes were sometimes the biggest wins at the demo!  As the end-uses got something that wasn&#039;t &quot;planned&quot; and was discovered on the route to the incrementally designed feature.  Sometimes it was a small feature that would be removed in a future sprint when the &quot;finished&quot; feature was again being worked upon.  But it provided value in the intermediate phase that the end-uses really liked.  WOW does that build good will and trust!  And allows the end-user to see how iterative/incremental development can benefit them.</description>
		<content:encoded><![CDATA[<p>Oh &#8211; I also want to add that we found the most pride in workmanship in the stories that we involved the end-users (or a representative) in the planning and in reviewing the stories as it was being built.  Which allowed for small and medium size changes in the story as the sprint progressed.  These small changes were sometimes the biggest wins at the demo!  As the end-uses got something that wasn&#8217;t &#8220;planned&#8221; and was discovered on the route to the incrementally designed feature.  Sometimes it was a small feature that would be removed in a future sprint when the &#8220;finished&#8221; feature was again being worked upon.  But it provided value in the intermediate phase that the end-uses really liked.  WOW does that build good will and trust!  And allows the end-user to see how iterative/incremental development can benefit them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Koontz</title>
		<link>http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/comment-page-1/#comment-18</link>
		<dc:creator>David Koontz</dc:creator>
		<pubDate>Wed, 04 Mar 2009 23:36:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileiq.org/?p=243#comment-18</guid>
		<description>On a past well functioning team I had the pleasure to be a part of, we also groomed the backlog at several meeting through out the current sprint.  It worked very well although not without the team being committed to doing the work!

We had 4 squads (sub-teams) one backlog and an excellent Product Owner who made decisions on the spot when required, and also give the grooming sessions plenty of her attention.

We did however arrive at some tips that may help others in the grooming sessions.  

We found that too many people in one session was more than 5 active participants in the conversations (sometimes more people were in the room - but typically more as observers, rarely involved in the debates).  

We found the PO frustrated by the development team rotating people in the sessions.  The lack of continuity was the cause of frustration, as we would often go back to past stories and a new dev. member of the group would not have the context for the discussion.  We resolved this by rotating on the sprint boundaries rather than the meeting boundaries.  The desire to rotate which developer attended the grooming session was a team desire, the PO wanted the same people each session.  The team felt that exposure to the backlog was a team responsibility that had to be shared, not shouldered by a few select members.

Our Business Analysis were frustrated by the constant writing and rewriting of stories and splitting and combining of stories.  There was a good bit of churn, and as everyone has a belly-button, everyone has an opinion of how to split a story!  But they soon learned that just the minimal information was required and that it took viewing the stories in different context and that this was not requirement gathering - but indeed product design that was happening right before their eyes, and they played a part of it!

We rarely got a story right!  That is at the grooming session.  We allowed that the story would be better understood at the planning game, and even better after work had progressed for a day or so.  Therefore the BAs took on the responsibility for documenting the negotiations in the story for the acceptance criteria that the PO and Team made on an ongoing basis.  This is important - no one can remember after a month why the story was acceptable with such-and-such a limitation, but the story if updated with the negotiated criteria can act as a &quot;as-is&quot; documentation - remember to record these or you will have a brewing misunderstanding on you hands.</description>
		<content:encoded><![CDATA[<p>On a past well functioning team I had the pleasure to be a part of, we also groomed the backlog at several meeting through out the current sprint.  It worked very well although not without the team being committed to doing the work!</p>
<p>We had 4 squads (sub-teams) one backlog and an excellent Product Owner who made decisions on the spot when required, and also give the grooming sessions plenty of her attention.</p>
<p>We did however arrive at some tips that may help others in the grooming sessions.  </p>
<p>We found that too many people in one session was more than 5 active participants in the conversations (sometimes more people were in the room &#8211; but typically more as observers, rarely involved in the debates).  </p>
<p>We found the PO frustrated by the development team rotating people in the sessions.  The lack of continuity was the cause of frustration, as we would often go back to past stories and a new dev. member of the group would not have the context for the discussion.  We resolved this by rotating on the sprint boundaries rather than the meeting boundaries.  The desire to rotate which developer attended the grooming session was a team desire, the PO wanted the same people each session.  The team felt that exposure to the backlog was a team responsibility that had to be shared, not shouldered by a few select members.</p>
<p>Our Business Analysis were frustrated by the constant writing and rewriting of stories and splitting and combining of stories.  There was a good bit of churn, and as everyone has a belly-button, everyone has an opinion of how to split a story!  But they soon learned that just the minimal information was required and that it took viewing the stories in different context and that this was not requirement gathering &#8211; but indeed product design that was happening right before their eyes, and they played a part of it!</p>
<p>We rarely got a story right!  That is at the grooming session.  We allowed that the story would be better understood at the planning game, and even better after work had progressed for a day or so.  Therefore the BAs took on the responsibility for documenting the negotiations in the story for the acceptance criteria that the PO and Team made on an ongoing basis.  This is important &#8211; no one can remember after a month why the story was acceptable with such-and-such a limitation, but the story if updated with the negotiated criteria can act as a &#8220;as-is&#8221; documentation &#8211; remember to record these or you will have a brewing misunderstanding on you hands.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brent Barton</title>
		<link>http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/comment-page-1/#comment-5</link>
		<dc:creator>Brent Barton</dc:creator>
		<pubDate>Sat, 14 Feb 2009 07:38:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileiq.org/?p=243#comment-5</guid>
		<description>Good comments, Jeff.  Proof that no two teams are really alike.  What I like is that you are about preparing for the next Sprint so it isn&#039;t a surprise at Sprint Planning! :-)</description>
		<content:encoded><![CDATA[<p>Good comments, Jeff.  Proof that no two teams are really alike.  What I like is that you are about preparing for the next Sprint so it isn&#8217;t a surprise at Sprint Planning! <img src='http://www.agileiq.org/wordpress/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Ramsdale</title>
		<link>http://www.agileiq.org/2009/02/06/what-the-hell-is-a-groomed-backlog/comment-page-1/#comment-1</link>
		<dc:creator>Jeff Ramsdale</dc:creator>
		<pubDate>Sat, 07 Feb 2009 03:24:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileiq.org/?p=243#comment-1</guid>
		<description>Recent projects I&#039;ve been a member of have found it too risky to wait until near the end of the sprint to groom the backlog. Also, as work is being wrapped up for the sprint it risks taking devs away from the delivery of that sprint&#039;s commitments.

As such, we&#039;ve found it works best to spread out grooming. Typically, with a two-week sprint starting on Monday and ending the following Friday the best time to groom without interfering with sprint start and end is Tuesday and Thursday. Hence, we groom for an hour each Tuesday and Thursday. Occasionally we&#039;ll schedule an additional session or two, but typically 4 one-hour sessions (along with the planning session) have been sufficient to prepare enough stories for a two week sprint.</description>
		<content:encoded><![CDATA[<p>Recent projects I&#8217;ve been a member of have found it too risky to wait until near the end of the sprint to groom the backlog. Also, as work is being wrapped up for the sprint it risks taking devs away from the delivery of that sprint&#8217;s commitments.</p>
<p>As such, we&#8217;ve found it works best to spread out grooming. Typically, with a two-week sprint starting on Monday and ending the following Friday the best time to groom without interfering with sprint start and end is Tuesday and Thursday. Hence, we groom for an hour each Tuesday and Thursday. Occasionally we&#8217;ll schedule an additional session or two, but typically 4 one-hour sessions (along with the planning session) have been sufficient to prepare enough stories for a two week sprint.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
