0

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!

Calie
  • 27
  • 1
  • 4
  • 2
    This question is off-topic because it's not within the scope for this site, as defined in [What topics can I ask about here?](//stackoverflow.com/help/on-topic) Also see: [What types of questions should I avoid asking?](//stackoverflow.com/help/dont-ask) You may be able to ask on [another Stack Exchange site](//stackexchange.com/sites#name), *perhaps* [pm.se] or [softwareengineering.se]. Be sure to read the help center's on-topic page for any site on which you intend to post a question. – Makyen Nov 22 '17 at 23:59

2 Answers2

4

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.

zzfima
  • 1,528
  • 1
  • 14
  • 21
0

+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.

Community
  • 1
  • 1
Regis
  • 11
  • 2