Breaking down tasks of user stories between developer and QA

Question

My team have recently gone to sprints and we are going through breaking down our user stories into tasks. What is the best practice in breaking down the user stories?

Should each task include developing, design, testing, and so forth? Or can the tasks be individually broken out? If so, should the tasks that aren't testing related just go straight to done and skip "Verify" or "To Test" column in the workflow?

From what I've read online it seems there is no 'set' way and people do it differently. I'm curious if people have had problems with their way of doing it.

Any help would be useful!

Answer 1

What is the best practice in breaking down the user stories?

Splitting user stories: the hamburger method

Elephant carpaccio

Should each task include developing, design, testing, and so forth?

As you wish. Maybe, you can test feature, not a task. But testing of small peaces (task) is easier, than whole feature (if it possible). BUT sprint product should be tested as well.

Answer 2

+1 for the Elephant Carpaccio :-)

The goal is to understand the power of thin and vertical incremental developments :

• Thin : the smallest code is written, the less code have to be changed for future stories
• Vertical : each story should change any part of the n-tier architecture code (presentation, logic, data), so that each story delivers immediate business value

I facilitated it and met his creator (Alistair Cockburn). This game/exercise is really interesting for teams facing customers with frequent change needs and small cash funds.