I agree with you about the estimation. In my company, we have a very formalized requirements process (dictated by our customer), and a lot of user stories being generated. Business Analysts like myself are writing these stories, and in many cases, we do not have the technical knowledge to realistically estimate them. For us, the estimation step occurs after a scrum team has decided to pick up a story out of the backlog. At that point, we hold a quick planning/grooming session where our tech leads and us BAs can talk about the stories we are going to work that sprint, and the devs will use "planning poker" or whatever method makes sense for a given scrum team to give a story a size estimate. I make it a point (as a BA) to NOT vote in the planning poker even though I am embedded in a scrum team.
I also agree that ACs should be part of the story before it is estimated. It is entirely possible for a developer to look at just the value statement and not fully see all the logical necessities that come out of it right away, and inaccurately estimate a story. To me, a story is not "done" unless it has acceptance criteria spelled out. For obvious reasons, I am also extremely careful if I ever have to touch ACs for a story "in flight" (already accepted by a team), because that is like messing with the goal posts during a football game. If I ever have to change an AC, it is with the agreement of the developer who owns that story and after carefully considering whether or not to just create a new story in the backlog (ideally, we should always do that, but we don't live in an ideal textbook-agile world).
As far as the best writing format for testing purposes, you can go either way. I find that the classic "As an X, I need Y, so that I can Z" works best because it is instantly comprehensible to any team member or stakeholder who comes across it. If you write it correctly, it should always be pretty easy to derive test cases. Very often, as I am writing a user story, I find myself thinking "how would I test this?". I also find it very informative as a requirements guy to go find our testers and pick their brains whenever I can. It turns out that they often have a different view of our application than a BA does, and "thinking like a tester" helps us close the logic loop when writing a good user story.
We have peer-reviews of user stories among the BAs on my project, which I think is good practice, and we end up having a pretty darn standardized way we write them. This is a good thing for a project as large as ours because our customer (or whoever) can go through the user stories and doesn't have to grapple with multiple types of user story formats.
As far as tasks, that really is an organization-specific question. For us, tasks are most useful when multiple devs end up working on a single user story. Tasks help us keep track of what each dev is doing. Our Scrum Masters like developers to break stories into tasks because it gives them a more granular view of what is going on and helps them estimate velocity. On our project, we also track tasks by hour, but stories by point. I think that isn't 100% agile-scrum "kosher", but it helps the project management team. Really, what you do or don't do with tasks is very dependent on what you are trying to keep track of, how you want to do that, and how you are organized.
