How to assign subtask to specific sprint

[Kan Wong]

Hello,

There is a need here to leave a task without sprint but assigning one of the subtask to specific sprint. The problem we having is how to add sprint field to subtask. And second, it is a proper way to use Jira that way. Thanks a lot.

[Benjamin Smith]

This self-imposed limitation in Jira is ridiculous.

Whether or not some feature or capability aligns with the scrum ideology, or any ideology for that matter, should not be the basis for allowing or restricting it. The question is, can it help people do what needs to be done given their particular situation.

Without even discussing the justification for including subtasks directly in sprints, it shouldn't be fundamentally restricted. Developers do not know every scenario a team may find themselves in or when a feature may be helpful / better than the prescribed methodology.

Since many people want this feature, and since this feature comes with relatively practical and relatable use cases, and since deliberately restricting this feature would be for the sake of ideological conformity...  it should have remained optional.

Jira can go ahead and throw up a warning any time you deviate from scrum methodology by enabling a feature or it can offer the prescribed method as an alternative, allowing the user to then happily click the button labeled, "Cool. I don't actually care but thanks. I'll take my chances."

Allow the tool to be as flexible as possible where it's easy enough to allow it. It may not align with the tool's original intent, but it may meet unforeseen needs or open the tool up for more novel uses, widening its market appeal.

All that said, my use case for subtasks seems pretty similar to all the other folks who ask for it. Alternatives like those proposed here seem very problematic.

Ultimately, we want a single Jira issue / ticket to represent a single deliverable (e.g. Create a an Inventory PowerBI Report for the Operations Department). 

We want subtasks to represent a chunk of work for that deliverable which can be accomplished in a single sprint (e.g. Gather requirements and research potential solutions).

It's uncomplicated and intuitive. Why subtasks are assumed to all be tiny little steps not worth pointing or tracking in a sprint is bizarre. Even simple steps can turn into more than we assumed they would be during a sprint, giving need to slap points on it and see it in the sprint so our managers know where our time is going.

Yes, we could use epics to represent each individual deliverable. The tickets within that epic would then be considered the measurable subtasks for sprint purposes. The problem here, though, is that

(1) We want to use Epics to represent larger scale initiatives or groups of related deliverables (e.g. Replace SSRS Reporting System Company-Wide). More than just preference, large scale initiatives like these show up quite naturally on our Jira Road Map. It gives us broad oversight into all the initiatives we have planned and currently in progress. It allows us to conveniently manage the start and end date of large scale initiatives, see how they fit into our sprints, and see the individual deliverables (i.e. Issues) involved in each and where they fall into the initiative's timeline.

Suggesting that we upgrade to the more costly version of Jira or use an addon to manage large scale initiatives (i.e. essentially create epics of epics), seems a very heavy-handed and costly solution, just to avoid breaking scrum ideals, putting points on subtasks and making them visible in sprints.

(2) If we were to make an epic for every single deliverable in our backlog, that would be 100 epics right there. Our Jira Road Map would be unbelievably large, giving no broad and automated oversight into the actual initiatives each deliverable was for. We could not use the road map to actually... road map the large scale projects we aim to complete in the coming months. The road map would become nothing more than a view of the backlog / planned sprints in the form of a morbidly obese calendar.

(3) Managing the relationship between individual Issues and their Epics is more work and less intuitive than simply clicking the "Create Subtask" button on an Issue. The relationship is immediately established by clicking that button on an Issue. Moreover, you can easily arrange the order of subtasks on the Issue by clicking and dragging them. Don't believe you can do that with the Issues displayed in an Epic. They are stuck and get cluttered really fast.

Yes, we could use a dozen other workarounds, but we lose intuitive usage, ease of management, and the benefit of built-in automated tools like the Road Map.

The scenario we're in over here does not seem unusual to me, so I'm puzzled as to why it's difficult for some to relate to the problem. You either use epics to track large scale initiatives for broad department oversight, losing the ability to break up individual deliverables into sprint-managed tasks, or you turn the road map into a vomit of disconnected deliverables, but gaining the ability to treat each Issue like a subtask of the deliverable.

If we're missing something obvious here, I'm not above admitting I'm a moron, so have at it.

[Nic Brough -Adaptavist-]

>This self-imposed limitation in Jira is ridiculous.

I am sorry to have to sound like I have not read the rest of your post, but I have. There's a lot of good thought in it, but despite the focus on "self imposed limitation being ridculous", it actually works out as "not doing it the way Jira pushes you to" does not work.

I'm going to pick out some things:

>The question is, can it help people do what needs to be done given their particular situation.

Yes. Probably. Jira is an issue tracker at it's heart, it probably can track the issues, whatever the methodology.

>Without even discussing the justification for including subtasks directly in sprints, it shouldn't be fundamentally restricted.

It's not "restricted", it is understanding that a sub-task is part of an issue

>Since many people want this feature, and since this feature comes with relatively practical and relatable use cases, and since deliberately restricting this feature would be for the sake of ideological conformity... it should have remained optional.

Again, it is understanding that a sub-task is part of an issue

>Jira can go ahead and throw up a warning any time you deviate from scrum methodology by enabling a feature or it can offer the prescribed method as an alternative, allowing the user to then happily click the button labeled, "Cool. I don't actually care but thanks. I'll take my chances."

Yes, and that's the howling anti-pattern we see ... just.. so ... too... frequntly...

You really need to stop doing that. You need your people to work together. Stop making it hard for them.

Ul> timately, we want a single Jira issue / ticket to represent a single deliverable (e.g. Create a an Inventory PowerBI Report for the Operations Department).

That is the defintion of a user story - do that.

>We want subtasks to represent a chunk of work for that deliverable which can be accomplished in a single sprint (e.g. Gather requirements and research potential solutions).

Yep, that works too - a sub-task is part of a story.

> It's uncomplicated and intuitive. Why subtasks are assumed to all be tiny little steps not worth pointing or tracking in a sprint is bizarre. Even simple steps can turn into more than we assumed they would be during a sprint, giving need to slap points on it and see it in the sprint so our managers know where our time is going.

As you already said, a sub-task is part of a story

I have not ignored the rest of your post, I think a lot of it needs to be re-read in light of this answer

[Jimi Wikman]

I hear you.

While we all wish the scaling of parent child items would not cost extra, this is the reality and we can't change that.

We also can't change the fact the Jira is built with a certain architecture where a story is defined as a work order and subtasks are internal steps to complete that work order. The epic is a container, the story is the work order and subtasks optional steps to complete the story.

What you are experiencing is the gap that exist as Jira is an operational tool designed for Agile teams. While there are some strategic support in Advanced Roadmaps, you still don't have any real support for strategy in any of the Atlassian tools, except maybe in Align that is still a black box for most of us.

For your mental model to work, you actually need at least one additional level, or you need to model things "sideways" by having two Jira projects where one act as the strategic level and one as the operational level. I know some teams add custom fields or abuse the components field as options as well.

I know that this is not what you want to hear, but that is the reality and it will not change anytime soon, unfortunately.

[Nic Brough -Adaptavist-]

It's not a "gap", it's supporting Scrum.

Scrum is for self-organising teams, it has nothing to say about groups of teams other than "make sure you work with others well"

This is not going to change, unless some new model of working (that fits with Agile and is wildly different to) comes along and is adopted widely.  If you do want to use Jira to work with groups of teams, then, yes, you should look to epps that enable Jira to do that - Advanced Roadmaps and Jira Align are the two that Atlassian will plug, but there are a few others in the marketplace (Big Picture, Structure, Easy Agile and so-on)

[Jimi Wikman]

@Nic Brough -Adaptavist-as far as I know, Scrum does not define what types of work you must use or in what structure they should be? It is up to each team, is it not?

[Dave Rosenlund]

@Kan Wong  As others have said, Jira was designed to (primarily) support individual teams. That said, there are lots of organizations that use Jira as a foundation for managing complex projects in a variety of ways.

Once you get past the fact that Jira out-of-the-box is designed to support your Scrum and/or Kanban teams teams — and that you'll have to extend it for doing things another way, you'll be fine. I personally know of many organizations that bend Jira to their will (and many others that like the way Jira imposes a uniform rigor to Agile processes).  I even know organizations that use a mix of the two — Jira as-is and Jira extended, to support a specific team's way of doing things.

@Kelly Arrey and his organization is a great example of this, as described in this article.

[Nic Brough -Adaptavist-]

Yes, that's at the root of my explanations here.

Scrum defines the "type" of work as "an item you can track, and hence work on during a sprint".  Most of us are familiar with those items being called Stories, but a better, wider, definition is something more like "sprint-able items". (A clumsy term, but I've yet to find a better short way to say it)

Jira implements the Story items as issues and lets you have many names for different types.  Sub-tasks are part of a story and hence not sprint-able items.

If you want to use sub-tasks to break up stories, that is entirely up to the team (Scrum is for "self organising" teams), but you have to understand that they are not sprint-able items themselves, they are a piece of their sprint item.

[Jack Brickey]

Not really, no. Sprints should consist of story/task level issues. Subtasks are just a way to add some clarity or break the story into smaller bits of work. Regardless of whether you use subtasks or not the full story or task should be completed within the sprint. Now for subtasks and their usage in sprints, they inherit the sprint from their parent. 

[Sage Arbor]

Atlassian enforcing this seems to go against the simple agile manifesto.  For example 2 of the 4 big bullets

* Individuals and interactions over processes and tools

* Responding to change over following a plan

I have read multiple posts where users are requesting agility with subtasks.  I would prefer if Jira was infinitely nestable , any parent child relationship we want, pointed, in any story.

[Nic Brough -Adaptavist-]

No, they're not going against the manifesto. 

They're supporting Scrum.   Components or parts of sprint items are not sprint items in their own right, that's nonsense in Scrum.  

It's not a case of "enforcing" anything, it's a case of "this is a Scrum tool, and this is how Scrum works"

I think there is a failure here in Jira's reporting functionality - I would argue that a sub-task should have a searchable (but not editable) sprint field.  It should inherite directly from its parent, so that you can see that it is part of a sprint (because its parent story is) when asking "show me everything in a sprint"

What you really want to talk about is if Scrum goes against the manifesto, not Jira.  I'd argue that it probably doesn't, but I'm no authority on it, just an ordinary scrum master.

[rokunin]

The problem is not in the field of "sub-task is a part of story" here but in that we need more nesting support. Nobody needs a sub-task to be alone in the dark and cold. We want a usable Themes-Initiatives-Epics-Story/Task structure, so one could decompose his project into deliverable bits and bins and put them into boards :) 

[Nic Brough -Adaptavist-]

>Nobody needs a sub-task to be alone in the dark and cold.

Yep, they're not, they're part of their parent!

>We want a usable Themes-Initiatives-Epics-Story/Task structure, 

Epic-Story-Task is built into Jira Software, so we already have that.  Atlassian recommend the use of Advanced Roadmaps to go up into Themes and Initiatives, and Align if you want to scale higher.

[Dave Rosenlund]

Hi, @Sage Arbor & @rokunin (welcome to the community).

I don't disagree with what @Nic Brough -Adaptavist-  said above in the least. This is exactly what Atlassian recommends.

However, IF you're looking for infinite nestability and flexibility I think you may find Advanced Roadmaps and Align to be more prescriptive than you'd like. They align (no pun intended) with Jira.

All is not lost...  There are other, and perhaps more affordable, Jira apps that add these capabilities to Jira.

BigPicture and Structure (full disclosure, I work for the company that makes Structure) are the ones I see "in the field" most often, but there are other options, too.

This search (or a similar search of your own) will help you find things you may want to consider:

Product: your flavor of Jira
Hosting Type: your hosting type
Best(?) Search Term in this case: Hierarchy (the same as nesting, but that's not a common term around here the way "hierarchy" is -- in fact, if you use "nesting" there are zero results returned)

Here's an example:

https://marketplace.atlassian.com/addons/app/jira/top-selling?hosting=cloud&query=Hierarchy 

I used "top-selling" mostly because that's what most people are looking for — tried and true.  But, admittedly, Structure is first on the list when you do that. ;) 

You can sort the list any which way you'd like of course.

Hope this helps, 

-dave [ALM Works]

[Nic Brough -Adaptavist-]

Sorry Dave, yes, I should have mentioned the alternatives!  I slipped up this time!

[rokunin]

Thanks, @Dave Rosenlund 

We use the corporate (and feature-wise much outdated) server jira solution with close to zero chance to update it to the Cloud, so we stuck there. Some updates come at some point, but almost all the fun stuff stays in the cloud or works super clumsy. We have the BigPicture plugin but the infrastructure is so huge (5k+ employees) that waiting time for say gantt or board update (Ctrl+R) could take literal minutes. So we're lurking there with some hopes of longer hierarchy that could come in a form of core functionality server update but I guess as or today we're hopeless :)

[Dave Rosenlund]

@rokunin  If I were you, I'd talk to the BigPicture folks about optimizing performance. I bet they can help you get that 5-minutes way, way down.  ;)

You probably already know this, but you can reach them via support@softwareplant.com. 

-dave

[Anna-BigPicture]

Hi @rokunin

Performance issues may be dictated by many different factors and have a totally different background, depending on, among other things, the use-cases of our plugins and the environment in which the plugins are used.

We always offer our assistance in solving issues. Therefore, please, raise a ticket via our Service Desk, providing us with more details. This will allow our product specialists and developers to investigate your instance individually.

[Marek Pałyga]

I see absolutely no reason why we couldn't add a subtask without its parent to sprint. Keeping to rigid scrum rules is absurd. There are projects and industries where it is necessary. But there are also those where it not only makes work and order more difficult, but also makes you not want to work with Jira.

An ideal solution would be an option that allows admins to enable and disable the option of adding a subtask without a parent to a sprint. It would be an ideal compromise between those who want to stick strictly to the principles of Scrum and those who want to run their projects in a different, more practical way.

I encourage you to vote for this feature:

https://jira.atlassian.com/browse/JSWCLOUD-5797

I am sure that when we collect only 1000 votes, Jira will introduce such a solution.

[Nic Brough -Adaptavist-]

Yeah, they should have closed that one with "not an improvement, won't do it" years ago.

Sub-tasks are not sprint items, they're a part of a larger issue.  See the previous explanations above.

[Allen Kwok]

Atlassian would need to do a paradigm shift from a prescriptive this-is-how-its-done Agile to a flexible, adapt-as-you-like Agile in order for something like this to go through.

[Marek Pałyga]

I read all your explanations. I don't agree with your theories. In my opinion, you are fanatically obsessed with the scrum methodology. I don't care what the name of the methodology I use is called. I am interested in the fact that the solutions I use work for my team and allow me to dynamically develop my business. Jira should not be a tool that blindly follows the rules of work in a specific methodology. Jira should be able to adapt to the user's needs. Jira should be a flexible tool. Otherwise, it will become a monument to its former glory. Just like Nokia today. I want to use hybrid solutions and I don't care what I call it. However, Jira is the closest to my needs out of all the available tools.

You know nothing about my projects and needs in my business. You don't know what the specifics of my industry look like, so don't tell me what my job should look like. I don't need 100% scrum, but something close to this solution. And yes, I can work 100% scrum. But in this case, I don't need it.

I don't want to start a discussion with you because I've read all your statements on this subject and I think you're a crazy man.

If Jeff Sutherland had worked according to the methodologies adopted at that time over 30 years ago, your scrum would never have even been created. Today you would still be creating Gantt charts. Don't limit progress.

[Nic Brough -Adaptavist-]

>I read all your explanations.

Thank you, it is good to be told that someone is listening to what you say.  When people write things and publish it, you don't get the feedback that you do from an in-person, or live-video conversation.

>I don't agree with your theories.

Most of what I have said is about how it works.  It's not something you can "disagree" with, it's not an opinion, it's how it is.

>In my opinion, you are fanatically obsessed with the scrum methodology. 

I take exception to "fanatically obsessed with Scrum".  I have obsessive tendencies (don't we all?), but "sticking to Scrum" is not one of them.  It would be more accurate to say that I am very pedantic about describing and defining things.  I'm very focused on accuracy and clarity, and that's about everything I work and live with, not just development methodologies.  

I don't really care about how you choose to work, beyond hoping that it works well for you!  If you and your team are happy with it, great. 

If you're working within a framework that has a name, fine, if you're not, also fine.  Just don't pretend you're doing <x> when you're not.

>Jira should not be a tool that blindly follows the rules of work in a specific methodology. Jira should be able to adapt to the user's needs. Jira should be a flexible tool.

It is a flexible tool.  The thing you seem to be missing here is that the parts of it that support Scrum are not suitable for doing things that are not Scrum.

>Just like Nokia today.

Heh, now that's an interesting story, but not for now.

>I want to use hybrid solutions and I don't care what I call it.

Yep, same here, do what works.  Just don't pretend to be doing Scrum when you're not, or try to botch Scrum tools to not do Scrum.

>However, Jira is the closest to my needs out of all the available tools.

Excellent.  It is a good tool, for a wide range of things.

>You know nothing about my projects and needs in my business. 

Nope, you've not explained it beyond "we don't do Scrum", I'm happy to talk about non-scrum ways of working with Jira, but you need to grasp that Jira Software's Scrum boards are for doing Scrum, so they might not be the right tool for your non-Scrum teams.

>I don't want to start a discussion with you because I've read all your statements on this subject and I think you're a crazy man.

Wow.  You've read all my statements on this here?  I'd say "scrum vs not-scrum" is less than 1% of my Community postings, but working with 1% means several thousand posts over the last 19 years...

"Crazy man" - I think you might mean that in a bad way, but I do not take it as such.  I think it means "someone who has such a different understanding of something to me, I really cannot grasp what they are thinking".  It's probably a two-way thing.

>If Jeff Sutherland had worked according to the methodologies adopted at that time over 30 years ago, your scrum would never have even been created.

Jeff's whole point of Scrum was not doing what you're trying to do. If you want to resort to name-dropping, I've worked in (Agile) teams that included Ken Schwaber and Martin Fowler.  And Jon Kern, whom I've separated out because I've not worked with him in a team directly, but I can (and have) yelled "hey, fellow Adaptavist, can you help?"

[Nic Brough -Adaptavist-]

You put a sub-task in a sprint by placing its parent issue in the sprint.  Sub-tasks are a part of an issue, not separate stories in their own right, and hence can only be part of a sprint by virtue of their parent being in it.

[Jimi Wikman]

Is there a reason you can not break out the sub-task to become a task instead? Also, what is the reason to not bring in the task itself? It can live in two sprints if you will only partially do the activities it contains?

[Crabtree_ Carin]

I have two teams with concurrent but separate sprints that regularly collaborate, so it would be nice to be able to have a subtask in the other team's sprint  

[Nic Brough -Adaptavist-]

It is well worth reading the other threads here (and not just the last ones - all of them have very useful things)

My 2d worth is that sub-tasks are a part of an issue, not a separate thing, so they should never even be seen by a different team (if you need that, create a story for them) but, I do not know how your teams work.

[Dave Rosenlund]

"if you need that, create a story for them"  👍

[Crabtree_ Carin]

@Nic Brough -Adaptavist- to be honest, I have been having a great time reading this thread!

It's a tricky situation - more like one big team that usually work on two different products (so two separate, concurrent, sprints) but they are integrated products so they must work together on a few topics, like regression testing.

I suppose then what I *actually* want is to be able to put an issue in more than one sprint, or be able to link issues in separate sprints in such a way that comments and attachments appear on both, or something like that.

My best solution is just that one team gets a dummy issue with a link to the "real" issue, which is fine, but messier than I'd like. Any other suggestions??

[Crabtree_ Carin]

@Dave Rosenlund This is more or less what we do, but it means we have a "real" ticket and then a "dummy" ticket on the other team's board that is just a link to the first one. It feels sloppy to me. 

The teams were not exactly open to my suggestion of a third board for collaborative items lol!

[Marco Trosi]

Like many others I had the same question

So I googled and I found all these answers here ...

https://community.atlassian.com/t5/Jira-questions/How-handle-story-with-subtasks-in-different-sprints/qaq-p/1519368

https://community.atlassian.com/t5/Jira-questions/Can-I-move-sub-tasks-to-different-sprints/qaq-p/957897

https://community.atlassian.com/t5/Jira-questions/Separating-sub-tasks-sprints-from-their-parent-task/qaq-p/1550519

https://community.atlassian.com/t5/Jira-questions/Can-we-move-subtasks-to-different-sprints/qaq-p/1039069

https://community.atlassian.com/t5/Jira-questions/Stories-and-Sub-tasks-in-multiple-sprints/qaq-p/1032445

https://community.atlassian.com/t5/Jira-questions/How-to-move-ONLY-the-remaining-sub-tasks-to-new-Sprint/qaq-p/1259047

(here) https://community.atlassian.com/t5/Jira-Software-questions/How-to-assign-subtask-to-specific-sprint/qaq-p/1534931

Short Answer is that SubTasks have to stay with their Story parent in the same Sprint.

In almost every discussion @Nic Brough -Adaptavist- is involved and has to give the same answers over and over again. I guess he is already very annoyed buy that reoccurring question.

I understand that Scrum is defined like that, and doing something else is then simply not Scrum, but something else that doesn't have a name yet. But if you try to sell it as Scrum then it's simply wrong-Scrum. All clear and correct.

But if so many ask the same question, maybe Scrum is just not the best for all companies and something new has to be defined. But who provides a flexible tool on the market that can be adapted to their use cases? Atlassian will not, that I can tell from all the answers in the links above. And that's okay, if Atlassian decides "we only provide a real Scrum tool" then that is their decision and it has to be respected, right?

So we also got Stories that can not be broken down into further logical parts, so we can only break them into fake pieces like "Task XYZ - part 1 of 2" and "Task XYZ - part 2 of 2" and then we can put them in different Sprints. Sounds like a job for Sub-Tasks, but as we learned it's not what Scrum defines. So instead we end up with 2 Stories, where one could think it's 2 separate Stories, but in reality it's the same task, only broken into pieces because the tool doesn't support putting Sub-Tasks in different Sprints.

Great, so none of the solutions above is really satisfying and maybe Scrum is not for everyone, or Scrum is not yet mature enough or many just try to mix their old habits with Scrum and end up with something that is not really Scrum. I don't know and I also don't care.

That were my 2 Cents cause it was fun to read all these Forum posts discussing the same all over again. Maybe it helps someone to come to a conclusion.

[Marek Pałyga]

@Marco Trosi 

Great research! I appreciate! And I share your opinion.
Recently, I came to the conclusion that the solution could be a completely new plugin that would work with a kanban board, but would imitate the backlog in scrum projects. In kanban projects, you can see tasks and add them without a parent.

I am at the stage of talks with developers and valuation of such a solution. Maybe creating such a plugin will be possible. I will accept any support from the Atlassian community to implement this solution. Maybe we should form a team to create something like this?

[Marco Trosi]

Hello @Marek Pałyga 
thanks for your feedback.
At the moment it looks like our company is switching to Polarion.

Sorry :-(

[Jarmo Parviainen]

Nice Chain. Waiting eagerly discussions about sub-tasks sub-task placing in sprints.

[Nic Brough -Adaptavist-]

You will not get any, sorry.  It's clear how Scrum works (and sub-tasks are not sprint items in Jira)

[Pál Heltai]

When I was young I thought, I knew better, how the users have to use our software, what is their business needs.

Now I am more experienced and know, users know better how their business processes should work and my task to give suggestions and a proper solution, not judge their practices. And if I don't give the proper solution, it ruin my own business as well, not just their. Maybe it would help on the stagnating share prices of Atlassian also if you are listen to your user's needs instead of indoctrinating.

Yes, maybe Scrum works on your theoretical way. However, as you see a lot of companies, teams use Jira and due to different reasons* they don't want or couldn't work how the Scrum work only want to use scrum tools (backlog, active sprint, burndown, etc.) to manage work and don't need hard restrictions based on theories and somebody's else business needs.

* For example 1-2 piece of work depend on the activites of a less agile customer or workphases of a story - development, functional testing, bugfixing regarding to this particular story, necessary firewall set up by a big and slow company - and could be only in the consecutive sprints. (Yes, workarounds are exists with other disadventages for example unmanageable amount of issues under an Epic.) 

[Nic Brough -Adaptavist-]

Same here.  But I've been working with Agile teams for over half of my life now, and the explanations I've given above have been learned from seeing those teams get it wrong.

I am not going to rehash anything I've said above, but I will summarise the conclusion:  stop expecting a Scrum tool to support a non-scrum way of working.

If you're going to try to do things like sub-tasks in different sprints, then you're not doing Scrum, and you might as well throw away the whole concept of sprints, and stop using a Scrum tool to manage your work.

[James Matlock]

Can someone point out where my thinking is going wrong, because I'm just not seeing the argument for the current way Jira deals with sub-tasks:

EPIC: A larger theme that doesn't always have a definition of 'done'. It could be something like 'automate employment referencing'.

STORY: an independent, deliverable unit that adds functionality or capability. This could be 'Use OpenBanking data to verify employment history' or 'Use tax data to verify employment history'. Any story should be able to be brought into a sprint and not be dependent on other stories being completed first.

TASK: a smaller task within a story. These are easier to plan and estimate than the story, can be allocated to different developers etc. This could be 'design the candidate data capture for automated employment history', 'build candidate data form in screening portal', 'test candidate form'. Each of these will have their own scope and requirements, like implementing validation in the candidate data form.

SPRINT: a cycle of fixed length with prioritised work based on team capacity with known deliverables.

REALITY: If I pick the most important and impactive stories that deliver the most value for the business, I may not be able to make them fit into exact 2 week sprints. So, let's say I have 4 stories, aptly named STORY1, STORY2, STORY3 and STORY4 and 2 developers.

STORY1 takes one developer 5 days to deliver. Great, We've got the most important story done! Concurrently, the other developer can work on STORY2 which take her 8 days. I mean, we're cooking on gas here... value, value value!

The first developer can then start work on STORY3, which is 7 days work. But wait, they only have 5 days left this sprint, what to do?!

Well, one option is to say to the business, I know this is the next highest priority, but we can't do any work on it at all, because Jira will only allow us to manage work that can be started and ended in a single sprint.

Another option is to take that story and split it into random parts, none of them being independent and thus not following INVEST principles, and some go in this sprint and some go in the next sprint, creating a random mishmash of part stories.

Or, they could work through the first 4 subtasks which get put into the first sprint, get it mostly done, and finish the last tasks in the following sprint, which would be the most efficient and valuable way to utilise that resource.

This is taken from Atlassian's own website 

(https://www.atlassian.com/software/jira/agile#:~:text=Jira%20Software%20is%20an%20agile,or%20your%20own%20unique%20flavor)

Jira Software is an agile project management tool that supports any agile methodology,

These are the 12 principals of Agile:

• Meeting end users' needs with early and continuous delivery of work.
• Being open to changes in requirements even late in the project.
• Delivering completed work at regular intervals, preferably short ones.
• Working with the project team and business owners daily.
• Assembling a motivated team, providing them with the right environment and support, and trusting them.
• Communicating face-to-face regularly.
• Using completed work to measure progress.
• Creating processes that promote sustainable efforts and a constant pace of work.
• Requiring continuous attention to excellence through good design.
• Encouraging simplicity.
• Recognizing that the best work emerges from self-organized teams that deliver the best architectures and designs.
• Reflecting regularly on how the team can be more effective and fine-tuning and adjusting the approach.

All the answers I see in relation to a story going across multiple sprints are saying that Jira won't do it because it isn't agile. What's not agile about it? Which of these principles does it breach? The ones in italic are principles that you are not supporting through your insistence of single sprint issues. You don't have to start and deliver a story in a sprint, you just don't, so please can you stop trying to make us!

I understand you're saying to use an epic as a story, which is actually what you're saying, but we want to use stories as stories and epics as epics and not create a load of mess in a paid product that is there to cleanly manage agile projects.

[Nic Brough -Adaptavist-]

The whole point of Scrum is that you deliver something useful or at least testable at the end of the sprint, showing the end-user that you are progressing.  This is well-aligned with Agile - it also focusses on delivery over planning, and looks for iteration - if needs change, it can adapt.

It is not Agile to promise you will deliver X and repeatedly fail.  Moving items to the next sprint fails Agile principles on points 1, 3, 7, 8, 9, 10, 11 and on point 12, you should be learning from your failures.

[James Matlock]

In my example, you'd deliver story 1 and 3 at the end of the first sprint, so box ticked. You'd then deliver story 2 and 4 in the next sprint. I think the example I give and the way I want to work it is perfectly aligned with Agile, it's just that I can't work on stories 2 and 4 in the first sprint because I can't get a developer to start doing some of the sub-tasks.

A good user story should be:

• “I” ndependent 
• “N” egotiable 
• “V” aluable 
• “E” stimable 
• “S” mall 
• “T” estable 

If I split a story into parts, just to fit them into Jira, I could feasibly have:

* Build API to new service

* Build front end UI for showing returned data to clients

* Test

Now, if these stories were Independent, I should in theory be able to say, forget the first 2, let's bin them off, just do the testing - but obviously that doesn't make sense. A story should be testable, not need a new test story to test a story.

You can show an end-user you are progressing without completing a story, that's why it's called progress. If you had a story that was split into sub-tasks, and you planned to get 6 of the sub-tasks done in sprint 1 and 4 in sprint 2, you haven't failed and you can show progress through the story by completing all the planned sub-tasks for that sprint.

I thin that's where people interpret this incorrectly. I'm not saying plan to deliver STORY2 in a sprint and then fail and move it to the net one. I'm saying plan to do part of STORY2 in a sprint if there's time to get cracking, as then you can deliver early and continuously the highest priority items.

How would you handle a STORY that's 2 weeks work, but in a sprint you only have 1 week left of developer time?

[Nic Brough -Adaptavist-]

Simple - be honest about it.  Do not bring the story into the sprint if you don't think you can deliver.

Again, you should not be drawing stories 2 and 4 into a sprint.  If you can't complete them, do not tell your users that you will, you're lying and you're not Agile.  Issues going into the next sprint is a direct indication that your process is broken - it is something you should be talking about your processes and why your team failed to deliver.

If a story does not fit into a sprint (and it's fine to have only one story in a sprint, if your team can all work on it), then you should not be committing to doing it.  It needs to be broken down - the Agile practice as applied to Jira gives you a relatively simple rout - promote the story to an Epic and then break that up into stories small enough to be delivered in sprints.

It's also fine to get ahead on a sprint, finish everything you promised, and then say "we'll do bits of the next things on the list as we've got some time left"

[James Matlock]

Don't bring a story into a sprint if you don't think you can deliver. That sounds like a madness to me.

So as I plan a sprint, I bring in the top, most important story and there is still capacity left. I bring in the next story, and there are 3 developer days left. The next most important story is 6 days of effort. In your process, what do I do? Is it better to ignore it and find the next best story that I could deliver in those 3 days, maybe that's the 9th story in the list...? Is this really delivering the most value?

And if I know I have 3 days to throw at the next best story, how is it 'failing' to commit to, say, 4 sub-tasks, deliver those 4 sub-tasks (which can be part of the sprint goal) and then deliver the rest of the story on day 3 of the next sprint, not on day 6 because I've arbitrarily delayed it just to fit a process? I'm not telling people I'll complete the whole story, I'm telling them I'll complete 4 sub-tasks and achieving that goal.

As for the notion that I should split the story into 2 stories, the first 4 subtasks and the remainder of the tasks so I can put a story in each sprint - that's equally crazy. When you write a story, you write the story, plan it, size it, get some back and fourth on requirements and scope... then you have to split off say 10%, or 60%, or 80% depending on remaining capacity of the sprint to shoehorn it in and say you finished the 'story'. 

Surely, being able to just allocate some of the tasks to one sprint and some to another, and have Jira account for the points in burn-up charts etc is more agile than the current process that, I think by your own admission, either prevents stories being properly written as per INVEST criteria, or introduces unjustifiable delays while you wait for a new sprint just so you can say you completed something in a oner?!

[Nic Brough -Adaptavist-]

>Don't bring a story into a sprint if you don't think you can deliver. That sounds like a madness to me.

I am sorry that this is going to seem rude, but I really don't think you have understood what Scrum is for.  (Or Kanban, or even Agile in general). 

It's about delivery.  You say "we think we can deliver X" and then you do, or do not.  It is completely binary - did you deliver what you said you would?

[James Matlock]

Could you just enlighten me as to how to deal with this in an agile way?

'So as I plan a sprint, I bring in the top, most important story and there is still capacity left. I bring in the next story, and there are 3 developer days left. The next most important story is 6 days of effort.'

Do I leave the story out of the sprint and start it next sprint when it can be delivered? Or do I turn one story into two stories?

If you can explain how to handle that in relation to agile, it might help shift my understanding?

[Nic Brough -Adaptavist-]

The simple answer is "do scrum properly". 

Pick a pile of well-understood stories that can be dealt with during a sprint, tell people you are going to deal with them, and then deliver them.  When you fail to deliver what you committed to, look at how you could improve.

If you end up with time left over, great, the team can dig through the other stories that were not selected for the sprint and put some time into them.  Ideally have them pick ones ranked most highly, and then take them into the next sprint with a head-start on them.

If a story is too big to be taken into a single sprint, then it is probably not defined well.  Most places I worked with (proper) Scrum teams move the story to be an Epic, and then create a load of sub-stories of work that can fit into a series of sprints.

But that's all about the way Jira represents stories, sub-tasks, and epics as a Scrum tool.  Scrum is a good fit for Agile practices because it listens and iterates, with the main emphasis being "delivering what people need now", over "delivering what people thought they might want several years ago".  The iteration in Scrum (getting stuff done inside a sprint) is all about delivering something closer to what the user needs, and you can't do that unless you can fit your work into scrum time boxes.

[James Matlock]

Thanks Nic, I genuinely appreciate your time and explanations and find the discussion to be thought-provoking, so thanks.

I think we're on the same page in that, broadly, you put in stories that you can deliver to the sprint, but invariably this will never neatly fit the exact capacity of your team. I also believe that the thing to do in this instance is to use the extra developer time to start cracking on with the next most important story so you can deliver it at the earliest opportunity.

Just to explore where you say 'If a story is too big to be taken into a single sprint, then it is probably not defined well.'... I agree that a story should be small, if you start at the beginning of a sprint and can't finish it in an iteration it's probably too large. But, with stories having a variance in their size, you can't start every story at the beginning of the sprint, you could feasibly start a story halfway through the sprint, hopefully we can agree that that's a thing? If so, then you get the scenario that a well-written, well-sized story could fit nicely into a sprint if you start straight away, but won't fit in the sprint if it's the 4th story in the list and I don't think you should change the goal, scope, deliverable of a story depending on how much of a sprint you can give to it.

What that means, I think, is that there are many feasible reasons why you would want to work on part of a story in a sprint, but Jira simply doesn't allow this. I think it's a problem that if you get a developer to do half of a story 'off the books' to get a head start, it doesn't count towards velocity, it looks like you've delivered the whole story in the next sprint and you can't reflect that some of the sub-tasks were done in Sprint 01 and the rest were completed in Sprint 02, and I think this is why people ask for the ability to allocate sub-tasks to sprints.

If you still disagree, it would be great to understand which part of my thought process is out of whack? :-)

[Nic Brough -Adaptavist-]

It is indeed rare to see a sprint where completion exactly matches the estimates, but the whole point is that you are measuring and reflecting on it.

If a team repeatedly rolls issues over to the next sprint, then you can consider them as failing.  Exactly where they are failing is a huge point of being Agile - they need to look at where they are failing, not just see it as consistently under-performing or team failure.  Why are they repeatedly failing?  The least common cause is actually a failing team, the more common causes are micromanagment, under estimates on task, poor planning, and the simple failure to understand what being Agile really means.

The bit that I think you have "out of whack" is not understanding what your velocity is trying to tell you.  "done" is a binary value - either something is done, or it is not.  

“Do or do not. There is no try.”

Or, "is it done"?

Sub-tasks are part of an issue, they are not independent items.  Your progress on sib-tasks is utterly irrelevant to whether the story is done or not.

Jira doesn't look at sub-tasks because it's total nonsense - an issue with 0 sub-tasks complete is the same as one with 30% done, or 99% done - it's not done.

[Marco Trosi]

@Nic Brough -Adaptavist- it's really fun to read this controversial thread, as it shows how an ideal scrum world and management expectations may not match.

I fully understand everything you are saying, ...

• if the story doesnt fit into a sprint it was planned badly -> agreed, no questions on that
• if there is time left in a sprint, we can start with other tasks that were not committed for that sprint -> agree on that as well, but I have 1 question ...
  
  How does Jira support me in showing management that the 3 unplanned days (from @James Matlock example) the developers are not sitting around and waiting for the sprint to end? I fully understand that they are not waiting, and that they started with tasks they had planned for the next sprint, absolutely okay, but how do I show it? Managment only sees 3 days of unused capacity when they look at the sprint planning. Do you say that Management should trust their developers that they start working on tasks from the next sprint? Not sure if it's only a matter of trust, it can also be an internal finance planning topic.
  
  I'm not saying that planning sub-tasks on a sprint is the solution, I'm only saying that managment wants to see 100% of the sprint planned, without any unplanned days. So how can Jira support us in showing management that the 3 days from the example are not waiting time? Maybe you say Scrum hasn't thought of that and so Jira also doesn't have to implement anything for it. But maybe you say Scrum hasn't covered that part, but Jira still wants to provide a solution that helps in some ways to show that 100% is planned. Maybe a solution outside of Scrum, for example to pull in some sub-tasks as potential candidates to work on if there is time left in the sprint. Means no commitment, just showing that these would be the tasks we would work on if there is time left in the sprint. This way we are still compliant with Scrum, and still can show that all sprint days are potentially covered.
  
  It's not about you being on Atlassian side defending Scrum and Jira, and the users on the other who have not understood Scrum. I think it's about understanding each others issues and finding a solution. The title of this thread never should have been "How to assign subtask to specific sprint" in the first place, as it suggests a non-Scrum solution. Instead the title should have been something like "Management wants to see 100% planned, what solutions can you offer?".