Re: How do you avoid scope creep when integrating user research into the scrums?
- I think the question of scope creep is real, even for an Agile project. Yeah, in theory the point of Agile is to expand or change the scope whenever your user feedback suggests it would be valuable to do so. In practice, the business has usually made plans based on certain deliverables, and your project has gotten funding based on prioritizing those deliverables over others. That creates an obligation to the business you can't just wish away.
Against this, it's absolutely true that user feedback is enormously seductive. It will cause the team to lose focus if you don't have any way to constrain yourself.
What we do is to split the problem in two. There's user research and concepting that precedes the start of Agile development proper. That ensures we get the right product and the right basic structure. A this point scope can be fairly broad. Referring back to Jared's initial post, because we do this we wouldn't be uncovering basic issues and misconceptions during Agile sprints. (And in fact we don't.)
Before we start sprints, we set scope explicitly by defining what usage cases we cover--what user tasks and situations the design is to support. Than any new extension of the system--which should translate to a new user story--can be evaluated based on whether it enables one of our defining usage cases or not. If not, it's not in scope, and implementing it requires buy-in from the business. If it does enable a usage case, it's in scope and we can prioritize it against our other stories.
In either case, I'd definitely write the stories. That way you don't lose the learnings, and you have the option to prioritize them in down the road if it turns out to be important.
And in either case, I'm assuming *real* user testing--with end-users, in their workplace, following their work tasks, not just usability tests on fake tasks in a lab. But doing that in the context of an Agile process is a whole separate topic. :-)