In our company we do usability test at the end of each Sprint. Many times we discover that the users don't like the implemented feature, so we either completely change it or scrap it in the next Sprint.However if we start doing potentially shippable product, thus fixing all bugs, running a lot of tests, preparing documentation for FDA and for users, fixing little UI issues - all this work will go to waste if users will not like the feature. Isn't it better NOT to do all this extra potentially shippable stuff until we are sure users actually like the feature?
Potentially Shippable Product Increment - what if users don't like the latest increment?
agile;scrum
Your sprints are too large or too complex. Your sprints are failing a key test, putting a lot of work in jeopardy. I believe that a risk (user's not liking an implementation) is not being managed fully or properly, causing extensive rework. Your team's project management style is at fault and you need to plan your sprints accordingly.Paper or screen mockups, accompanied by lots of handwaving, are much less expensive than code to produce (I'm assuming: you might instead have a killer UI mocking framework). A walkthrough or role playing with appropriate test subjects takes dramatically less effort than building and making a system ready for deployment. Since you already know that user acceptance is high-risk, and that you likely won't get it right the first time, you can plan for multiple iterations within the current sprint in order to get the feature set right.Since a sprint should not have deliverable elements that depend on elements from earlier in the sprint, you should not plan to deliver the UI/feature elements that you decide on during the current sprint. Instead, the results of the testing inform the planning and development of the following sprint.In my experience, it is not unreasonable for a sprint to include, let's say, a) code and finishing for hard-and-fast features, b) tech spikes for sprints indefinitely in the future, and c) UI & feature tests for sprints in the near future. This allows you to manage the high risk stuff while continuing to deliver solid, acceptable code with all the proper documentation, etc, that accompanies a product release.In my last project, we had a sprint constructed with a mix of a) a one-paragraph description of a feature or UI element for review by the user group, b) a screen-shot walkthrough and hand-waving session, c) a prototype ready for play-testing of a feature from a previous sprint, and d) a ready-for-final-acceptance testing feature that was first presented two sprints ago.