Nope – Executive Brief has permission to republish that article. I appreciate you catching it (just in case)! Thanks, and welcome to Tyner Blain!

http://www.executivebrief.com/agile/prioritization-agile-teams/

Great point about continual reinforcement of outside-in versus inside-out. Agree about the tendency to slip. Especially when the internal team has a greater mind-share from the product owner (or product manager) than the external influencers. Easy to get mis-reoriented (or mis-reorientated depending on the flavor of English you speak).

Good data point re: UX. Another thing that it is difficult to remember – the first design does not have to be the final design. Getting a visualization that enables the story is the first goal. Improving that visualization is something to be prioritized for follow-up. This opens Pandora’s box of “big up-front design” discussions – which I wrote about in Nov 2008, Satisficing Sprints, in the context of providing something that is “good enough.”

In the first sprint, we propose an interaction design that may be good enough. We quickly get feedback from customers and / or stakeholders. Based on that feedback, we decide if it was good enough. If it wasn’t we decide if closing that gap is more important than the other items on the backlog. If it is, we iterate on the design for that. If it is less important, we tackle another story.

One item which I believe is conveyed in you post via the inside out/outside in comment is the basic tenant of writing a story from the users perspective. (As a I want to accomplish ). We find that this continually has to be re-enforced/reminded. It seems to be a natural tendency to slide from outside in perspective to inside out, and then you lose customer focus.

On UX: In our shop we are very lucky to have a great interactive design team. However in our structure they are outside of the product/development teams so we interact as needed with them similar to an internal consultancy. They helped us create some design standards that we can re-use and engage as new concepts come up that don’t seem to fit the guidelines. However more often – we do simple wireframes (with visio, powerpoint or balsamiq) as needed based on the nature of the user story. Even if they are not optimally designed for the user experience, often they help visually convey complex topics to a development team more quickly than text or words. They also help frame up the problem, so that we can create a more sucinct (smaller) set of Acceptance tests.