I like to use the INVEST criteria as a guideline. http://xp123.com/articles/invest-in...art-tasks/
I like to bring this up in the retrospective (perhaps have a retro focussing on this point).
I also reinforce the need to spend 10% effort reviewing and maintaining the backlog to prevent this recurring.
For mobile development I have found having wireframes essential, and depending on the composition of the Dev team, the specific assets required as well.
The acceptance tests get written in the Sprint - and I encourage the use of Gherkin syntax to specify acceptance criteria http://docs.behat.org/guides/1.gherkin.html
The team will tell you if you go too granular, and the timeboxing of the work maintaining the backlog will prevent you slipping in to task breakdown.