Most often, I see the teams get cold feet when writing user stories as they are not sure if they are getting it right. My usual response is that there is no perfect user story and that he purpose of user story refinement  is to ensure that each user story has sufficient detail so that it can be programmed, tested, and integrated within a single sprint.

User story refinement increases efficiency of the team by greatly reducing risk by minimizing the unknowns. Having a adequately refined backlog greatly reduces the time required for a Sprint Planning meeting as all the team is able to have common understanding of the development that will be undertaken.

Always start by identifying thin vertical slices of work that can deliver business value. For example if a user login functionality has to be developed, the deliverable would need to have User Interface, Application logic and database tables. As opposed to developing the complete data model in the first sprint, application logic in the second sprint and the UI in the third sprint.

Typically it is recommended to work through enough backlog items that would last about 2 Sprints beyond the current sprint. This is to ensure that the team can still function if the Product Manager or Product owner are unavailable for a week or two.

As a prerequisite, ensure that the backlog is ordered to reflect the business priorities specified by the Product Manager or Product Owner. This will ensure we work on the user stories that have high business priority and need to worked on relatively soon as opposed to later.

User story or an epic? the best way to address this question is to follow the rule of thumb, which is if a user story cannot be completed in one sprint then it has to be split into one or more stories.

It is also a good practice to check if there are any internal or external dependencies for a particular user story and capture the dependency. This will greatly help during the planning session when the team is committing to a bunch of user stories.

Finally, almost all user stories require acceptance criteria, wherein one will specify when a user story can be considered completed or done and working as intended. This will also guide the Test and QE teams members of the team to appropriately write test cases.