Carl Bruiners Agile / IT Development Consultant

Difference between a user story and a story

A user story defines the requirements of the business and is written by the PM along with a BA (if available / possibly the same person), the user story is then broken down into individual stories that can be delivered against, which in turn is broken down into individual tasks.

Sounds simple, but in practice it is often not achieved. If you don’t break down User Stories you’re always working against Epic scale stories. It is critical to break down user stories into multiple stories so that each story is deliverable within an iteration (or if using Kanban ensures it can fit into the swim lanes).
It is important to break down stories into tasks so that you have a clear vision of what needs to be achieved to deliver the story. Having tasks also allows us to understand during an iteration how much time is remaining. Story estimations are finger in the air stuff, in particular if you are using relative points as your measurement, task hour / day measurements helps us to understand the actual remaining time against the original story estimation. Long term this will help improve your team’s ability to better estimate both user stories and stories.

On a side note, even though acceptance criteria is only a must have for user stories and stories, I also encourage teams to have acceptance against a task. Doing this increases QA throughout the whole of the process.