nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Valerie Boudrea

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.

Accepted answers

All comments

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:

Split the top-level task into pieces that can be done in a sprint
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 Boudrea

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 Boudrea

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.

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-core

scrum

sprint

sub-task

story