Let me explain our situation. We are small company with about 20+ staff and all the while we have been practicing the standard waterfall model with not much success (due to frequent changes of requirements and lack of direction).So one day our CTO came in and he briefed us about SCRUM and all of us were convinced that this model will work great for a small team like us. Unfortunately all of us do not have any experience practicing SCRUM and we have been relying mostly on online resources and books.Then we come to a new project that we are about to get started and we are doing something like:Gather requirements from  business domain userPrepare a requirement spec with UI and features (this already took us like weeks)Meet up again  business domain user to see if there is any changes requiredOnce the business user agrees to the specs we will key in those feature in to product catalogBreak those features into tasks and assign to sprintShould we instead take the more agile approach? likeGather requirements from stakeholdersStart to create epic user stories and run through with stake holdersBreak those epic stories into smaller stories (supported with some ui) and    assign to a  short sprint(2 weeks)We show them what we have done for the 2 weeks, get their feedback and plan for the next sprintGiven the nature of our projects where we are constantly faced with the challenges of volatile requirements and a lack of direction, where will the above Scrum/Agile points benefit us and why are the above Waterfall methods failing us?
Where is Waterfall failing us and can Scrum help us have success in our projects?
agile;scrum
The second approach is much more in the spirit of agile/scrum, but it also requires a commitment from the customer to visit regularly to see the progress and discuss further features.If the customer is uncomfortable with such a commitment of effort on their side, or if they already have a very good idea of what they want to have, then your first approach might be more constructive.One of the key points of scrum is that the customer gets a big say in the order in which things are produced, so let them clearly indicate which features they would rather have sooner and which features might end up in the bin if the budget gets too stretched. And don't kick up a fuss if the customer changes his mind on some requirements/stories, especially if they haven't been implemented yet.An alternative approach, in a more scrum-like manner, but similar to the first approach, is like this:Gather requirementsSplit requirements into stories and put them on a backlogStart first sprint with stories create architecture and UI proposalDuring the sprint, discuss your proposals with the customerRefine the backlogAs each sprint ends, pick the next top X stories from the backlog to implement.