To break work down into managable tasks while retaining a nice and clean link back to the overarching story, we use sub-tasks. For the life of me, I can't figure out how to view, rank or otherwise assign those sub-tasks to a sprint individually.
After trawling these boards and seeing a cascade of similar compliants I am trying to determine a few things:
More details about what we do
The problem I have now is that the only way to solve this problem is to have the all my sub-tasks appear as major tasks. This causes a couple of issues.
Firstly, there is no nice clean way to link them to their parent as core parts of the same overall task.
Secondly, as a matter of policy we force people to record story descriptions according to a certain template. This helps ensure the high-quality of stories and helps properly categorise them as stories. Basically, we only allow people to register issues of Epics, Stories or Defects. From here, we break the story down into a bunch of small tasks (similar story to many) which may be of various differnet types (New Feature, Improvement, Documentation Task, etc...). This puts a real organisational distinction between what is requirements (Stories) and what is implementation (everything else) and overall results in a higher quality of reporting and a simpler process for everyone.
If I have to move all sub-tasks to regular tasks so that I can do crazy things like assign them to sprints, I'll have to make it possible for all the various types to be registered. The only way from then on to keep this policy is to enforce it with a big stick, which is fine and all, but creates a lot more work.
I'm fine with this if it's just an internal technical limitation. I can understand that and live with it, but if it's because I'm not doing "Atlassian-certified" Scrum... Well, I get a little frustrated then, so I'm just trying to figure out where it all stands and what the likihood is that it'll ever get changed.
The sad part is, if rapid boards didn't look so awesome I wouldn't care.
I agree with Tim here - we would love to use sub-tasks to break down a specific story into, well, sub-tasks :)
It makes perfect sense for us here - for example, suppose we have a story called "Implement Big Bang Theory": we would like to break this down to:
One can argue that this is in fact an Epic - but the problem is, we have 100+ of these concurrently at any given time, which won't work well with the current Epic UX... sub tasks seemed to us the perfect balance... until we saw they won't show up in the rapid board :(
+1 for feature to enable subtasks as work in Jira Agile.
People manage projects using WBS (tasks, subtasks). No subtask in JIRA Agile means JIRA Agile not good for managing a project. It isn't any more complicated than that. Work-arounds, are, well, work-arounds (Epics, Stories, links, etc.).
I agree with Arik and team.
Our development team needs validation from governances before we can start coding. The architect/development team is first making solution and technical design to be submitted to the governances. So regarding the development team one story is composed of 3 sub steps, Solution design, technical design and development. We often need to plan the 3 steps across different sprint.
We use one main issue with 3 sub tasks to correctly follow the lifecycle of one story.
Using normal issue with link makes more difficult to follow the story. Time management on main issue includes subtasks when normal link does not. Furthermore we are using link to…link issue. For example if they are related or duplicate stories.
Using Epic to split a story in sub steps will makes the real usage of Epic unviable. We need Epic to group different story together as a bigger level. Not in term of step but as big picture of different story.
I’m a not an expert in Scum, but having Greenhopper not managing subtask in plan mode, makes us to not be able to use it. This is really frustrating as we love the way it ease the management of the team. We are now making all the planning manually without the possibility to make real statistics that Greenhopper provides.
And I do not see any other way than subtasks to use Jira with our workflow constraint.
+1 on this being un-cool. I can't use the new rapidboards until this changes. They finally added the versions to the rapidboards and i had hope but I need the team to be able to view sub-tasks. Until then, I'm stuck in classic mode and so is my team. -Steve L Coupons.com
Come on Atlassian, open up the settings.
I don't expect this to change as the design is based on the fact that a story is planned as a whole in a sprint. If not, the size of the story is too big which calls for a change in the way the backlog is groomed into stories.
See Shaun's comments in this thread.
I've seen Shaun's comments and unfortunately they don't give me much hope. I guess the real problem here is the misunderstanding that a User Story is an entire, atomic work unit.
It's not just a matter of needing to break things down into further stories because one is too big, but rather, it's a matter of needing to break a story down into its different sub-components which may have different priorities and even different assignees. The completion of a story as the overall driver for "work" might include a bug that needs to be fixed, and an additional improvement to some comopnent, some documentation updates and an addition to our QA test suite. Each of these tasks only make sense in the context of the driving story and each may have a different level of priority. The use of Sub-tasks is not always a matter of size, it's a matter of compsition.
It's the assertion that I *must* have stories that are too big and thus I'm "doing Scrum wrong" that gets me going a bit. That's the idelology bit that's preventing me from being able to use the tool and that's why I'd be disappointed if it were the case.
Ranking is still possible acros sub-tasks while in work mode, but planning is always common (same sprint). While I agree completely with your statement here "The completion of a story as the overall driver for "work" might include a bug that needs to be fixed, and an additional improvement to some comopnent, some documentation updates and an addition to our QA test suite." , they having different priorities is somewhat unacceptable to me.
This means that these tasks are being done by different teams, am I right? Or members of the same team? If members of the same team, it looks quite disturbing to me that they have different prioties. Scrum makes a basic assumption that the teamed is united in terms of the Sprint goals and they do what is needed to push our or complete the most important story in their list.
If they are being done by different teams, Tim, it is high time to think about getting them together. Once you see the speed at which the story gets finished when they are in the same team, you will be thrilled.
They're not being done by different teams, but we will slip certain tasks to batch them together for efficiency (a few orgainisational things we have to deal with). That's beautiful idelogoly, but the process we have works well. The tool however does not work well for that process and the only thing preventing it is the inability to view sub-tasks as standalone items in the plan view, which feels kind of arbitray, but whether or not it is or there is something technically deeper at work is what I'm really wanting to know. If it is idelogoy then that's cool as well. Sad, but it does save me some money as I drop back to just using vanilla Jira.
That's what we'll have to do, but unfortunately it breaks the strong association between the tasks and thier driving story (links just aren't the same) and means that I'll have to update the statuses so that all the different technical task types are available as top level tasks. I'd previously restircted this down to Epic, Story and Defect, and provided nice cut/paste templates for people to use when registering these (gives some consistency and raises the quality of reporting). The lack of being able to register tickets of any other type greatly assists in driving conformance to the development process, taking away the need to chase people with a big stick, which is fine, just time consuming and ultimately, perhaps more pain than just living without the boards.
G'day guys. I've just given up here and assimilated.
The recent updates to Jira and Greenhopper have taken away much of the pain. There is now an easy way to drag/drop issues onto Epic's to form the association, and with Epic's listing their associated issues in the same way tasks/subtasks did before, and individual issues showing badges of the Epic they are linked to, most of my complaint starts to disappear. So all in all, with the current state the number of complaints I have are now limited to smaller things. I'm going to close this off as answered so that I stop getting email reminders for me to do so, but I do hope that the later versions of Jira/Greenhopper are also yielding similar stories of lessened issues for other people as well.
G'day Michal, We use Stories as the unit of work (anywhere from one hour to a few days) and then use Epics to wrap up strories across sprints. To get a more coordinated picutre of where we are heading at a higher level, everything is assigned to a particular upcoming release version and that pretty much covers all we need. Release planning through to longer "cross-sprint" tasks and down to the individual work unit level.
I feel like this limitation isn't due to the ideology but rather due to the lack of understanding of the methodology. Short users stories are not the only entities that can comprise a sprint. It's perfectly acceptable to have time-boxed tasks like spikes, for example. You have a user story that you can't estimate because it has unknowns, so you schedule a 2 hour spike into a sprint. Or you have a bug report. You can't just schedule a bug into a sprint because it has too many unknowns. First a bug needs to be reproduced, which is a time-boxed activity. Second RCA needs to be performed. A time-boxed activity again. Finally, the bug itself is getting fixed. Sub-task designations are perfect for time-boxed activities.
...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....
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!
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