Technical tasks as subtasks of Stories a bad idea?

Hi,

creating a Story and seveal technical tasks under it creates a dillema or at least I do not know how to handle the scenario when not all of the technical tasks are resolved by the end of the sprint in the Rapid Board.

Ending the sprint moves the Story and all subtasks to the new sprint!

How do you handle such scenario? Is it not possible that resolved subtasks are left behind and only Story and unresolved tasks are moved forward to the new sprint?

2 answers

1 accepted

Hi,

It's a little unusual to have a story with tasks where some of those tasks get completed and others don't. In that case many people would say that the story therefore isn't complete and it should go back to the backlog (with it's tasks that are still marked as complete).

I can see your point that in some circumstances a task or two might not make it, there are two ways I think you could deal with this:

  • Convert each of the subtasks that did not make it in to a full story (or full issue). This makes sense because if you want to consider the story done then logically the not-done subtasks must be freestanding
  • Create a new story and move the incomplete subtasks to be children of that new story. Again the this makes sense because the new story must describe what hasn't been done and how it's freestanding

In the future we plan on implementing a 'Split story' function in to GreenHopper. This would allow you to split the story and keep the done subtasks as children of the existing story but have the not done subtasks attached to the new story (so they can go in to a future sprint).

Thanks,
Shaun

0 vote
Thomas Schlegel Community Champion Jul 12, 2012

Hi,

I think this behaviour is correct, because the tasks belong to the story and if the story is moved to another sprint, all the task are moving with this story, because they all are parts of the story.

If they should stay in the closed sprint, they would need a new story they can belong to. This has to be handled manually.

Cheers

Thomas

If one goes into the detail planning, that is specifying all the technical tasks, one can easely create a task or two which for whichever reson do not get completed by the end of the sprint.

So the alternative is not to create subtasks (technical tasks) and only stories, which makes the process of removing them manually from the sprint with the menu action "Remove from sprint" or automatically to the new sprint a no-brainer in greenhopper rapid board.

You have to be really sure to end all the subtasks within the sprint to use them! That somehow defeats the idea of estimating work if there is no tool support to easely manage such cases. Don't you think?

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Sarah Schuster
Posted Mar 28, 2018 in Jira Software

Can a company’s culture make or break agile adoption?

Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...

13,128 views 15 13
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you