I am currently wondering what is more beneficial in kind of setup:
1. Create one Epic - Assign x userstories, define tasks per userstory as subtasks.
2. Create one Epic - Assign x usterstorries, assign Tasks (not sub-tasks) to the userstories.
My goal would be to be able to organize working simultaniously on various userstories - but not having to complete the whole story in one sprint.
It would be perfect in our case to use Stories to group tasks and discuss and track progress in matter of what to present to the customer / Product owner, but depending on what teammates are currently available in the sprint (multi-project organisation still) able to put each tasks into sprints more or less independently from stories.
So i can open a userstory, and let it calculate the remaining amout of hours on that story, and i can use a sprint to plan the optimal use of ressources (testers, programmers, analysts, etc.)
So, anyone out there who has the same requirement and can share best practise a bit?
Kind regards form winter-cold Austria
This is going to sound harsh, but when you say
"but not having to complete the whole story in one sprint."
That tells me you are not doing anything resembling Agile Scrum. You might as well throw away sprints, simplify estimates down to non-time-boxed numbers of hours, and treat epics as simple themes to help reporting.
As for sub-tasks, they are, by definition, part of a story. Treat them as such. Or split the story so the ones that really are part of the original story are, and the ones that move to the new story are not.
And I should really have answered the question too.
Either of your strategies would work, but if you want to do Scrum in any useful way given what it sounds like you are doing at the moment, you will have to use the second one.
Stories should be completed in a sprint. (I say Stories, but it's any type of issue at the story level - i.e. not sub-tasks and not epics). That's the whole point of the sprint. You are telling your product owner that you are committing to delivering a set of them, and you should complete what you said at the end. If you don't, you need to spend time working out why. If the answer is "Dave got sick" or " Emergency bug hit us", fine, you have a good answer. If the answer is "we over estimated what we could do", then you learn from that and lower your commitment in the next sprint. If you don't, you're lying to your product owner about what you can realistically do.
Jira (rightly) has no way to carry over partial completion. Sub-tasks are an irrelevance to the sprint as they are part of their parents, and are part of their parent. It does not matter if you complete no subtasks, half of them 99.9% of them - their parent, which is what you said you would do, is not done. Only when they're all complete does it matter.
So if you have a case where you are seeing a lot of carry over of issues with sub-task at the end of your sprints, do two things:
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events