From spec to tasks you can start working on
How to slice correctly
Slice by value, not by layer. “Screen,” “server,” “database” are three tasks none of which delivers anything until all are done. “The user can save a draft” is one task that touches three layers and ends in something you can show.
When a task is too big, look for the variations: happy path first, edge cases later; one user first, many later.
What must be on the card
Context in a line — who needs this and why. Acceptance criteria in a consistent format. A dependency if there is one. And a link to the spec or discussion that spawned it.
What shouldn't be there: a detailed solution. If every card dictates the implementation, you've eliminated the reason to hire developers.
Signs the slicing is bad
A task that rolls between work cycles, a task “almost done” for three days, and a task you can't test without three others. In all cases the cut was by technical structure and not by result.
Going deeper
Write the acceptance criteria before you start writing code — they define the test. A task you can't phrase acceptance criteria for is usually research in disguise, and then it's better defined as such: a time-boxed slot, a defined question, and a written output.