You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We created a task that had several subtasks. It's not possible to finish the entire task in a short time so we would like to plan several sprints to complete this task. But in my planning board, I can only see main issues, not sub task issues. The advantage we have with subtask is that we can update time against the subtask and it will update the total time in the main task which helps us with time planning. Separating the subtasks into other tasks would leave us no way to do that so we can't really use main issues for these items. How can we solve this?
Hi, this questions pops up all over the place and I don't really understand, why it has been implemented in Greenhopper 5 and when talking about Greenhopper 6 it seems to be the devil himself when it comes to SCRUM.
People acutally work that way and for us this is as well a no-go for Greenhopper 6.
Our tasks, that deliver the business value very often consist of a lot of subtasks for different subsystems of the project, as functionality spans over various aspects. When we define such a user story (=task) we usually define all subtasks already and try to estimate these to get a good feeling on the total duration. This is often longer than a sprint and I already hear you saying "break down the task", but as told before, many times, this is not desirable, since creating smaller tasks that don't deliver the desired functionality in itself and grouping them by epics or links makes it harder to track such a feature and closing smaller "New Feature" tasks, that acutally don't deliver a feature would clutter our reporting.
Even worse, we're not able to do the sprint planning with the new planning board, as a feature which holds a lot of estimated subtasks will on it's own exceed the time for the sprint.
Thus we usually plan only a couple of subtasks. It wouldn't be very helpful (as suggested on another thread) to let such an issue "travel" through on sprint after the other...
Anyway, I don't expect Atlassian to reconsider it's decision regarding the subtasks, but just wanted to let you know, that this way we are not going to move forward to GH6 and thus won't upgrade our maintenance as well... Another customer lost.
This is bad and Atlassian should feel bad for doing this. I've read the canned response from them about you should use storys or something something story points but when I go to break up a large task into smaller ones so I can accurately predict and measure the results I would expect the paid scheduling tool I use to be accomodating.
Rigid != Agile
We organize the development of bigger functionalities using epics, which we break down to stories for single features. As we are developing mobile applications in two specialized teams, we cannot always ensure to have one feature being developed in the same sprint by both teams, which is why we would have loved to use sub-tasks that could be put in different sprints but we can´t. I´m a big fan of JIRA but, sorry Atlasian, this decision really sucks.
We managed to get around this by adding an extra label indicating whether the sub tasks should be included in the sprint or not, and adding a custom filter to the sprint board using this label. Only the sub tasks we want now show up and the estimated time only includes the correct sub tasks.
@Fabian Valencia I'm not clear on your point. @Beatriz Beatriz seemed to be saying that there is a "development team" that has decided that subtasks cannot be added to sprints, separate from the Atlassian Team. However, this feature is an Atlassian feature. So how can there be a separate "dev team" that made this feature decision?
I don't think Beatriz was referring to customers/users.
Another vote for this "functionality". Thought the whole point of agile was the ability to work the way its best for the team/project and not be restricted to a specific approach. Come now Atlassian. I need the ability for clients to see a larger task being worked on, but not the entire thing.
For example, we use Epics to define the functionality the client wishes to achieve. We use Stories within the Epic to define the various sub-component uses (customer, system, admin, etc) for their specific experience/functionality, and we use sub-tasks to define the efforts within each of these stories. The stories collectively in the Epic can be lengthy (a few months or longer to complete) and each story can be lengthy (a few weeks or more). Our sprints are a week at a time generally and we'd like to be able to put the tasks within a story into a sprint so that the client can see the portion that is being worked and we can properly track the story as a whole. But... my hands are tied without the ability to see to the level of a sub-task. Sometimes the customer knows better given the real-world experience.