Agile methodologies are all about including your users and user groups as stakeholders who are active throughout the development cycle of the project. Remember the
Agile Manifesto:
Business people and developers must work together daily throughout the project.
But are you really prepared for the results if you empower your users?
Case in point: A project that I was on was divided into two releases. One release had iterations totaling about 7 weeks.
Toward the end of week 1, we had two mockups of the user interface, done in Visio, that we presented to the user group. This elicited a lot of conversation about the features in each release, and the definition of project success. In the end, the user group stated that they preferred that a key feature be moved to the second release, that they could live with the minimum functionality of the first release, and that they probably would not authorize continuing with the second release because they had other initiatives that they would rather have IT tackle and spend "their" money on - things that would more effectively impact their department's bottom line. So this is essentially scope contraction.
None of these concerns specifically came out in the earlier project charter or requirements sessions, although they were considered risks when analyzing the definitions of success for the project.
The question is: could your agile team "handle" this outcome, suck it up, and honor the user group's request? Or would you as a developer be too "invested" in the design and project at this point and be defending the original design?