How do I put some sub-tasks into one sprint and the rest of a task's sub-tasks into another sprint?

[Valerie Boudreau]

We are an IT department. We have each of out IT sub-departments set up as a project. When a project comes in, we create a task in the department's project. Our work legitimately breaks into tasks with sub-tasks which are often done in different sprints. When a customers asks for storage space and we have to buy a server, sub-tasks of the new server may be to research a new server purchase, make the purchase, receive delivery and rack it, get it online and map it, notify the user of his new storage location, none of those is worth delivering to the customer by itself. We may purchase the server and wait three weeks for delivery. 

If I try to put some of the sub-tasks into one sprint, all of the story points for the whole task goes into the sprint and falsely fills up the sprint. The math of the sprint is rendered useless, hence the planning of sprints is rendered useless. 

It does not make sense for us to break the new server task into multiple tasks. We aren't delivering anything useful to the customer or to ourselves in each of those tasks. They are not separate user stores. 

[Nic Brough -Adaptavist-]

You don't.

Sub-tasks belong to a parent issue.  You put that issue into a sprint.  Its subtasks go with it.  It doesn't make sense in Agile to do it any other way (because if you do, you might as well throw out all the planning stuff)

Your options are:

1. Split the top-level task into pieces that can be done in a sprint
2. Accept that Story points will be completed in the sprint in which you finish the task (although this sounds like a disaster, it can work if the cadence of your incoming tasks vs delivery works out.  But it does take a few sprints to get the right numbers out)

The main problem here is that you're managing a non-Agile process with an Agile tool.  Personally, I'd bin the planning part of the Agile stuff, as it's not going to work, and head for Kanban instead.

[Valerie Boudreau]

We were using Kanban and, after spending 3 weeks setting our projects up in it, we discovered it doesn't have a planning feature. Useless for us. So we switched to Scrum, which appears to also be useless for us. I inquired before we went ahead with JIRA if it can be used by an IT department or if it was really just for software development. You won't enable us (Kanban) or allow us (Scrum) to use it the way we need to. JIRA's main product isn't a software application. It's a philosophy on Agile. One that not everyone shares.

[Nic Brough -Adaptavist-]

Ok, so Kanban doesn't plan. It's good for support type stuff in general, and Kanban boards are quite handy for knocking up alternate views of Scrum and completely-non-Agile stuff. But that's a bit of a digression here. The problem you have here is that you're trying to use Agile Scrum methodology (the part where you commit to delivering a certain amount of work in a time period) for something that is not Agile. Your process is not Agile and hence the tool doesn't handle it. Scrum isn't just for Software development. It works for all sorts of things. It doesn't work for everything, and that includes your staged waterfall process with time and delivery based dependencies. JIRA Agile supports Agile processes. What you are doing is not Agile. JIRA Core can help you and support you in that, but Scrum really isn't intended for your process. Hence my comment about binning it and heading for Kanban (although I should really have pointed out I meant Kanban is more for the quick views than the actual process)

[Valerie Boudreau]

My question isn’t what does anyone at Atlassian think about how we define Agile. It’s about whether or not your software can help us conduct business – can we use it as a storage center for our project workflows, communications, other administrative records, can we pull from it the reports and other types of information we want to view, and can we configure it to do that in a time-efficient manner. I couldn’t care less what labels you do or don’t put on our methodology. I’m not bothered by your opinion of Agile for software development being different from my opinion of Agile for IT. I have gone from what I call a waterfall approach where I lay out a linear project with end to end tasks that happen sequentially, to a project methodology where every two weeks we look at the total of IT tasks on our plate and plan which ones make the most sense to do next according to where our projects are at, what priority each project had, has and is changing to, what business requirements have changed in the rapidly moving business we serve, the discoveries we ourselves make as the project progresses, and what resources we have available to us. A reassessment every two weeks of where we’re at, where our projects are at, and what is best for us to do for our customers and ourselves during the next two weeks. That’s Agile for us.

Where as in software development one would create one project for the ongoing development of Software Product A, one for Software Product B, etc., and do version releases from each project, we would be creating 600+ projects in JIRA per year, one per IT project. That overhead is prohibitive. On the advice of our Engineering dept. who uses JIRA Agile for the software we develop for sale, we created six ongoing projects, one per IT sub-department. As each IT sub-department creates a project in JIRA, they create an issue per project, and a sub-task per task of their project.

We have a lovely and useful Kanban board where all four of our task types, which we have called Projects, glide nicely through our project lifecycle/workflow; Steering Committee Review, Discovery, Design, Scheduling, Build, UAT, Done. We have lovely individual sub-departmental Kanban boards where each of the tasks of the sub-department’s projects (which JIRA calls sub-tasks) glide across the board from To Do, to In Progress, to Done. What we’re getting from our Kanban boards are a record of our actions; the ability to create Dashboards and reports that show the status of our projects by the phase they’re in and the remaining work. We can view all of our outstanding project tasks (JIRA sub-tasks) in a single backlog, prioritize them, view the story points of each, and know the total story points we want to pull into the next sprint. What we can’t do is pull our chosen tasks into a sprint and have those tasks alone add up to the points for the sprint. The whole project gets pulled into the sprint, with all of its tasks, and the total points for the project, though we are attempting only some of the tasks of the project. JIRA's math is useless for us. And there is no clarity of tasks to be worked on during the sprint. When the sprint ends, JIRA can’t accommodate what we want to do with our tasks and how the project should proceed to be ready for prioritization and remaining story point selection for the next sprint, as all of that functionality is unavailable for JIRA’s sub-tasks.

FYI, IT isn’t a service desk and JIRA Service Desk doesn’t accommodate our projects. One of our six IT sub-departments is a Service Desk and that will work well for them, but the rest of IT needs the ability to administer projects that can span months and which have their own project lifecycles and complicated workflows.

Perhaps our problem with JIRA Agile isn’t at the bottom end, sub-tasks. Perhaps it’s at the top end, Epics. It would be fine if sub-tasks couldn’t be split across sprints if we could create multiple types of Epics. Because we have to create our departments at the project level to avoid project overhead, and our project types as the task level, we are forced to use JIRA’s sub-tasks as our primary project tasks. We seem to need "just one more level" to work with. 

I comprehend that we can clone a project. But our Engineering dept, who uses JIRA for software dev, insists the overhead of creating a project for each of our 500+ projects and managing those hundreds of projects as JIRA projects would be far above the time and effort we can afford. We can’t go that way. Each of our 25 person IT dept is hands on the keyboard performing project work, including our IT managers. They need to be able to whip off a project as a task to the already established project that their department is, and create sub-tasks for the tasks of their project. But then … they have to complete their entire project in one sprint because they can’t spread sub-tasks across sprints without taking in all of the story points for the entire project into whatever sprint they want to put one or more subtasks into. We are stuck for a way to use JIRA Agile in a way that is a win for us. Yet I like your product. I like it because we want to use what our Engineering dept is using instead of introducing yet another app to the company. I like how flexible it is in many ways other than how it isn’t flexible for us. I like how easy it is to learn how to use its features.

Honestly, JIRA could support our desired use of it, and the many who desire to use it in the way we do – with the ability to spread out sub-tasks. But for those at Atlassian who believe they should rule over how we want to do Agile, when frankly, it’s none of their business.

The irony of all of this is Agile was developed so people could run projects with more flexibility than waterfall afforded. Sadly, some have damned it to be as inflexible a methodology as waterfall is. Just with a unique set of inflexible attributes. 

[Nic Brough -Adaptavist-]

You are missing the point here. You have a process which works for you. It doesn't fit in with the Agile model because it's time and dependency based, and Agile planning is based on completing things within a sprint. JIRA Agile is aimed at Agile processes and hence is not aimed at your process which is too far away from Scrum to be usable. Your planning and process are simply too far away from Agile to fit into the model. Your point about Epics though - that's a clever idea because it would mean your stories could fit within a sprint. p.s I don't work for Atlassian, I work for one of the partners.

[Valerie Boudreau]

All a moot point now. Atlassian tossed everyone out of Kanban and Scrum if they're not software development. At least they gave us 3 business days notice so we can find another vendor, make a purchase, get up running and complete training.

[Nic Brough -Adaptavist-]

Well, not quite. You don't have to be doing software development to be Agile, it can be applied to all sorts of things. I'm not convinced that "Software" was the right name for what they've done with Jira 7 + Agile because I know of places that will be going to Software despite not having a line of code. Because they're Agile. When you're looking for a new system, I'd strongly recommend avoiding "Agile", as your process is too far away from it to be useful. In fact, JIRA Core can handle most of your process, with a little bit of config, but I think your process benefits hugely from the board style visualisations, which you can't (yet) do in plain Jira Core.

[Jeremy Lawson]

Can't this be solved using linked tasks instead of sub tasks?

In agile, a feature with many components which span sprints is sometimes called an Epic.

In Jira, an Epic is a primary issue, and it can be "blocked by" many other primary issues of type Task for example.

Let's not get hung up on the term "agile" which spans many meanings and methodologies.

[Eric Smith]

Valerie really nails it.  People want the simplest of functionality and we're told no because "Well that's not how you do Agile."  I'm not sure why Project Management software companies are so hung up on this - Hansoft does it as well.  

We need the ability to be flexible with our PM tools and methodologies, which means sometimes we need to customize our projects per team.  

Personally, I would want to use sub-tasks to keep track of pipelines so that nothing gets dropped through the cracks.  Except I can't seem to do that, because sub-tasks can't get assigned to different sprints, nor do they show up in the board.  Useless.

[Nic Brough -Adaptavist-]

If she'd "nailed it", she'd have grasped why it's nonsense to do that.

[Eric Smith]

It's funny, I've been searching for a resolution to this issue across this community, and you seem to be in every thread, covering for Atlassian.  You're not helping.

[Nic Brough -Adaptavist-]

I'm sorry that explaining why it's the wrong thing to do is not helpful to you.  But unless you understand why it's wrong, I can't change that.

Please, have another read of the explanations above, you clearly don't need to be doing sprints for planning if you want to do this, so you should really be looking at other ways of working.

(And, they do appear in boards, so I'm not sure what you're looking at)

[Eric Smith]

Yeah, they appear in boards once you make sure that your filter explicitly asks for them.  Using "Epic Link = Whatever" doesn't work - which always annoyed me.

Also, you can't see them in the Backlog, yet another annoyance.

I get your arguments for why Jira Agile doesn't support this - but at the end of the day there are lots and lots of users who ask for it.  We shouldn't be chastised by Atlassian because we happen to be using their product in a slightly different way.  They (and you) are choosing to die on this hill for some reason.  

I think a lot of people use subtasks because certain tasks have many moving parts.  It's a good way to make sure that a multi-discipline task is completed fully, and nothing falls through the cracks. Plus, we can templatize it, which saves time.  But because of the absolute inflexibility that Atlassian continues to show - it's a non starter.

[Nic Brough -Adaptavist-]

I'm 100% with you on the epic link failure.  I know a task belongs to a parent and the parent has an epic, but not getting it cascade down is wrong.  We (recently) got the JQL function "parentEpic" on Cloud, but those of us on Server are still stuffed, and it's a decade later than it should have been.

You don't need subtasks in the backlog really, as they belong to their parents, it's logically wrong to rank them outside their parents, and the backlog is for the parents.  (Although it would be nice to rank them inside their parents there sometimes)

I think you also need to have a look at volumes.  Sub-tasks across sprints goes outside Agile Scrum because it breaks all the measuring and makes a nonsense of doing sprints.  Atlassian have dozens of people asking for it.  They've got tens of thousands asking for priority schemes (7.6! Yay!  At last!)

It sounds to me like your processes are not really suited to Scrum.  I'd be looking at Kanban instead (and if you have Cloud, the Agility boards)

[Eric Smith]

Again, you don't seem to grasp that you're telling us how to manage our projects.  All we want is a tiny bit of flexibility in the software that we pay money for.  Your response is "well you shouldn't use our software that way." 

I say that I want something, and you say "you don't need that."  It's silly.  It's not like this is the only issue - there are tons of very simple requests that the community has, and we're basically told that we're using Agile wrong.

It's like if I ask for a napkin for my cheeseburger, but you say "Well, I'm not going to give you a napkin because you should be eating it with a knife and fork."

[Nic Brough -Adaptavist-]

No, you've missed the point again.

This is quite a subtle distinction, but I'll try to be blunt so it's more obvious.

I'm not telling you how to manage your projects.  I'm telling you to stop trying to use the wrong tool.

There is nothing wrong with your management of projects, but it is not well-served by trying to use Scrum methods to do it.  It is not a good fit.  Hence, a tool designed for Scrum, such as Jira Software's Scrum boards are not a good fit.

It's like if you ask for a napkin for my cheeseburger, but I say "Well, I'm not going to give you a napkin because you appear to be ice skating, not eating a cheeseburger, and I might distract you"

[Andy - PTC Redundant]

As a horrendous project nerd who will use Agile, (Iterative) Waterfall, or PRINCE2, dependent on the project at hand [don't forget, the key to effective project management is to customize the methodologies and processes available], I support the point  @Nic Brough -Adaptavist- is trying to get across. 

If I look at the initial question, on top of consideration of planning in TEMPO and Kanban vs Scrum, I would say the Work Breakdown Structure needs to be re-addressed. I'll think on it and come back with a separate answer out of this long chain. Hopefully that will help.

[Bogdan Gorka]

Let me share with you with one of the use cases that was presented to me about the IT Service world in JIRA. First of all, IT Service is a process, however it can be 'agilised' a bit. First of all, all work that flows into an IT department is registered in ONE project. Other service departments have their JIRA projects, eg: HR, Purchasing etc. In IT department all work that flows in, let's say it is setting up a new server, is called a work package. This work package is categorised using Project components. Now, if a work package flows in, it is then decomposed by a team leader into tasks, Tasks are then stored in backlog waiting for the next resource planning meeting. During that meeting, tasks are prioritised and put into weekly sprints using the Tempo Planner plug-in. They can be planned in time and put into, what Tempo calls, weekly Iterations. These iterations can then be put then on a timeline and people's time utilisation can be analysed. Next, if a person feels that his/her work should be split and shared with the team mate, can generate subtasks and assign them to other people. I guess that looking into the Tempo add-in may help you. JIRA is a great software, however utilising it to its full potential requires knowledge about the business processes and JIRA functionalities which often have to be supplemented with add-ons.