Take it iteratively. You're working directly with the users, right? So it should never really be a mess.
First do the search page. You and the users should keep in mind that they'll want to be able to do actions on the results. Do the users like it? OK, you've got your search.
Now add the "Change Password" (or whatever is next in priority). Oops, we need to change the search page a little--well, change is often part of the game. Do the users like it like the results? Good.
Now add the next item, and the next...
The agile approach says you always have feedback right away, so you should be good.
That said, there's no real reason why you might not be able to attack 2 of these stories in the same iteration (adding delete user AND ban user). The key is to always be working with the customer to make sure it's right.
You're often (always?) going to end up with users thinking of something else they want to do from that search screen after your original "design" is done and implemented. So, you'll end up modifying it at some point anyway. Just approach the whole thing with that expectation and you should be good.
how do you handle dependencies in sprint planning?
Ideally, non-development dependencies are handled before sprint planning, so that you have a good definition of the backlog item to estimate effort against.
But, if that was "just development for you" last sprint, then that was probably going to be just development for you this sprint, so you should really have increased your estimate there and then on upcoming tasks that are in a similar state. This is not being vindictive, and it would be a mistake to let it come over as such.
What it does is shows the uncertainty of estimation without a relatively solid design to estimate against. Perhaps, this will encourage your managers to make sure that a product backlog item is properly defined; but at worst it will cover your back. No one complains when a job come in under-budget.
However, you didn't do that, and now your question is ...
how should I now approach the sprint?
The whole purpose of Scrum as a project management tool is to identify problems early, which you've done. Flag it up to your management, let them decide what to do with the sprint. If they try to blame you, be humble and ask how they suggest you approach similar situations in future, to avoid the same problem, even if you don't truly believe that it's fair.
At the end of the day, these are project management issues, and if you try to solve them within your own bubble, you're setting yourself up to fail. And, when you do, you'll be angry because it'll fall on you, not on the managers who failed to solve the problem when you flagged it up to them.
Best Answer
A user story is typically created from a need expressed by the client or potential user of the system. It's often of the format "As a {role}, I want {goal} so that {benefits}". The collective set of user stories capture the functionality desired in the system that is being built. The customer or customer representative prioritizes each user story, typically based on the value added by having the functionality specified in the story.
Once written, user stories are sized and estimated. There are a number of techniques to do this. The most common method of estimation that I've seen is the amount of effort needed to complete the task, in arbitrary values. There's a base unit that everyone can agree on, and use this as a common framework for providing estimates as to the effort required. I've seen these as being unitless values called "story points", but I don't see why you couldn't also estimate the user story in hours. The key is to be consistent across all user stories.
For the first iteration, the team estimates how many story points they can complete in a given iteration and move up to that number of points into the backlog for an iteration. If you are estimating in hours, then you can determine how many hours your development team will dedicate to the project during the iteration and pull down that many hours worth of work. After the iteration, you determine how many points or hours that you actually completed and pull down that amount of work for the next iteration.
During the entire process, your overall backlog of stories is changing. Features might be removed, new features can be added, or the priority can be changed. However, none of this affects the work that was pulled down for the current iteration. Only between iterations should you adjust what you are working on. You will typically either have an on-site customer representative or someone who can act as voice of the customer and is in contact with the appropriate people from the customer's organization. They are continually refining the requirements and acceptance criteria throughout the project.
How you further break down user stories into tasks is up to you. It might be an undocumented preference of the engineer, or there might be a detailed analysis of exactly what each user story entails. That's something that needs to be specified by tailoring the process to meet the needs of your organization, team, and project.
You should have a definition of done, which can be used to determine when a particular user story is shippable. This defines everything from design, implementation, testing, quality assurance, acceptance criteria, and documentation. You can specify what tools and methods you use to ensure that a given feature as specified by a user story is done. Once a user story is done and integrated, the product should be in a potentially-shippable state, meaning that packaging it and delivering it to the customer would add some value to their operations or meet some of their needs.
Ultimately, you need to tailor the processes to work for your organization, team, and project. Doing anything "by the book" is usually a recipe for problems. Just because something has been documented and works well for certain teams working on certain projects doesn't mean that it fits everything that you need it to do.
You might be interested in this InfoQ article on user story estimation as well as Scott Ambler's Introduction to User Stories.