Do you simply not know what you're trying to accomplish? How can you decide how to do something without knowing what it is that you're trying to achieve?
In my world, we define our tasks by what the end result of the work is, i.e. what is user visible. We do not normally define tasks with implementation details (although sometimes fixes or refactors will mention them). We don't really discuss how we're going to do it, we just say what we did yesterday (that was user visible), what we're working on today (that will be user visible), and identify anything that's holding us up (that is visible to the individual being blocked). Sometimes we'll elaborate with a few implementation details as they can be interesting to team members (e.g. yesterday I was struggling with bugs in our memory manager), but strictly speaking that's not what I got done, that's an excuse for why I didn't get more done.
Estimations may be way off, especially when just getting started. The more estimates you do, and the more you look at estimated time vs. actual time (e.g. by tracking velocity), the better your estimates will get. On our team we have pretty consistently hit a velocity of 50%, so for our two week sprints we schedule 40 hours of work for each person. We have not, as a group, endeavored to make our estimates any better since the consistency is working for us and we're ok with our velocity being consistently low.
The key to scrum, in my opinion, is feeding knowledge back into subsequent sprints. You learn a lot during a sprint, so be sure to use that knowledge to make the next sprint better. If something's not working out for you or your team, spend some time in the retrospective meeting to come up with changes that you can make to fix the problems. We're pretty far off from "by the book" scrum but I would say we're still embracing the spirit; it works for us, we adapt to changes pretty easily, and we get the stuff we signed up for done by the end of the sprint. Our variations come down to acceptance that fires will come up mid-sprint and we have a mechanism to deal with that that does not require the whole restart process.