<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	>
<channel>
	<title>Comments on: UIEtips article: 12 Best Practices of UX in an Agile Environment &#8211; Part 1</title>
	<atom:link href="http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<lastBuildDate>Thu, 18 Mar 2010 16:06:49 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Amber DeRosa</title>
		<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/comment-page-1/#comment-145717</link>
		<dc:creator>Amber DeRosa</dc:creator>
		<pubDate>Tue, 03 Mar 2009 14:20:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=705#comment-145717</guid>
		<description>Thanks Jeff Patton, This is a great article!

Agile can work...if implemented correctly. Its here embrace it. I have had success on many Agile projects by being part of the team and integrating myself into the process. UX team members cannot work in a bubble and expect Agile teams to listen to recommendations. Be Flexible find ways to make it work. 

2) Research, model, and design up front - but only just enough
 &gt; A vision/direction becomes more important on an agile project. If no direction is set, an Agile project will design and build software features that are not used. Rather then cutting requirements you will end up removing large chunks of designed pages or worse putting them out there with the product just because they are finished. 

4) Use parallel track development to work ahead and follow behind
&gt; Working in a parallel track or working a few sprints ahead is vital to integrating requirements and UX work into an Agile team. 

7) Schedule continuous user research in a separate track from development
&gt; It does not have to be in a separate track, but it must be done before and after coding. A separate track may make it easier to schedule or plan but it is not necessary. Getting a sprint or two ahead of the development team is vital, user research is nearly impossible during the sprint the story is being coded. (not impossibly just nearly ok just a lot harder) Save yourself some heart ache and get a sprint or two ahead. Also complete the User research of the developed system early enough to incorporate the feedback; during functional testing, is a good time because the team is still making changes on those stories. Teams don’t like to close stories and then open them again for usability changes. If this happens make new stories for usability changes. 

8) Leverage user time for multiple activities
&gt; A must!

10) Prototype in low fidelity
&gt; testing wireframes early identifies any direction changes or big items.
&gt; testing the developed systems identifies interaction and other finite issues. 

12) Become a design facilitator 
&gt; Become a part of the team! It is up to you to sell and influence.</description>
		<content:encoded><![CDATA[<p>Thanks Jeff Patton, This is a great article!</p>
<p>Agile can work&#8230;if implemented correctly. Its here embrace it. I have had success on many Agile projects by being part of the team and integrating myself into the process. UX team members cannot work in a bubble and expect Agile teams to listen to recommendations. Be Flexible find ways to make it work. </p>
<p>2) Research, model, and design up front &#8211; but only just enough<br />
 &gt; A vision/direction becomes more important on an agile project. If no direction is set, an Agile project will design and build software features that are not used. Rather then cutting requirements you will end up removing large chunks of designed pages or worse putting them out there with the product just because they are finished. </p>
<p>4) Use parallel track development to work ahead and follow behind<br />
&gt; Working in a parallel track or working a few sprints ahead is vital to integrating requirements and UX work into an Agile team. </p>
<p>7) Schedule continuous user research in a separate track from development<br />
&gt; It does not have to be in a separate track, but it must be done before and after coding. A separate track may make it easier to schedule or plan but it is not necessary. Getting a sprint or two ahead of the development team is vital, user research is nearly impossible during the sprint the story is being coded. (not impossibly just nearly ok just a lot harder) Save yourself some heart ache and get a sprint or two ahead. Also complete the User research of the developed system early enough to incorporate the feedback; during functional testing, is a good time because the team is still making changes on those stories. Teams don’t like to close stories and then open them again for usability changes. If this happens make new stories for usability changes. </p>
<p> <img src='http://www.uie.com/brainsparks/wp-includes/images/smilies/icon_cool.gif' alt='8)' class='wp-smiley' /> Leverage user time for multiple activities<br />
&gt; A must!</p>
<p>10) Prototype in low fidelity<br />
&gt; testing wireframes early identifies any direction changes or big items.<br />
&gt; testing the developed systems identifies interaction and other finite issues. </p>
<p>12) Become a design facilitator<br />
&gt; Become a part of the team! It is up to you to sell and influence.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Paddock</title>
		<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/comment-page-1/#comment-145676</link>
		<dc:creator>Chris Paddock</dc:creator>
		<pubDate>Thu, 26 Feb 2009 00:33:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=705#comment-145676</guid>
		<description>I understand how Agile can be beneficial from a development perspective, and I do like how there is a more inherent sense of collobaration and overlap of project phases, but why is this a better approach for Product Managers and Designers? And outside of theory, why is it a better approach to make more usable and desirable products?</description>
		<content:encoded><![CDATA[<p>I understand how Agile can be beneficial from a development perspective, and I do like how there is a more inherent sense of collobaration and overlap of project phases, but why is this a better approach for Product Managers and Designers? And outside of theory, why is it a better approach to make more usable and desirable products?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/comment-page-1/#comment-145661</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Mon, 23 Feb 2009 21:40:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=705#comment-145661</guid>
		<description>Hi Jared,

Thank you for pointing out this post. I have found Accurev to be an important element of our agile practices and wondered if you had ever heard of it? I&#039;ve never used anything that allowed teams to adapt so quickly and give visibility into what everyone was doing. Now if we could just figure out how to keep our velocity in check when adding in time for bug fixes.

http://www.accurev.com</description>
		<content:encoded><![CDATA[<p>Hi Jared,</p>
<p>Thank you for pointing out this post. I have found Accurev to be an important element of our agile practices and wondered if you had ever heard of it? I&#8217;ve never used anything that allowed teams to adapt so quickly and give visibility into what everyone was doing. Now if we could just figure out how to keep our velocity in check when adding in time for bug fixes.</p>
<p><a href="http://www.accurev.com" rel="nofollow">http://www.accurev.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pages tagged "agile"</title>
		<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/comment-page-1/#comment-143321</link>
		<dc:creator>Pages tagged "agile"</dc:creator>
		<pubDate>Mon, 04 Aug 2008 04:48:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=705#comment-143321</guid>
		<description>[...] bookmarks tagged agilebatch photo resizer UIEtips article: 12 Best Practices of UX in an Agi...&#160;saved by 3 others  &#160;&#160;&#160;&#160;NEMESIS1999 bookmarked on 08/03/08 &#124; [...]</description>
		<content:encoded><![CDATA[<p>[...] bookmarks tagged agilebatch photo resizer UIEtips article: 12 Best Practices of UX in an Agi&#8230;&nbsp;saved by 3 others  &nbsp;&nbsp;&nbsp;&nbsp;NEMESIS1999 bookmarked on 08/03/08 | [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: UIEtips article: Part 1 - 12 Best Practices of UX in an Agile Environment</title>
		<link>http://www.uie.com/brainsparks/2008/08/01/uietips-article-part-1-12-best-practices/comment-page-1/#comment-143295</link>
		<dc:creator>UIEtips article: Part 1 - 12 Best Practices of UX in an Agile Environment</dc:creator>
		<pubDate>Fri, 01 Aug 2008 18:17:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=705#comment-143295</guid>
		<description>[...] Original UIE Brain Sparks [...]</description>
		<content:encoded><![CDATA[<p>[...] Original UIE Brain Sparks [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
