Configuration so that Sprints ignore Subtasks

[sgover]

I have a use case where a development team uses a subtask issue type to document production deployment steps for the work produced as part of the parent Story.

Unfortunately, production deployments do not align with our sprints (due to other factors outside of the team's control). The Done criteria of the Sprint is for the Story to be Deployment Ready. The Board is set up as such.

Unfortunately, since the Deployment Step subtask is not done at the time the Story is considered done for a sprint, I am unable to Complete the sprint. 

We've considered many other alternatives for documenting deployment steps. I don't have details, but after a lot of analysis and testing, they came up with the subtask issue type as the best solution. However, this is a major snag. 

Any ideas for how to get around it? Ideally, I'd be able to configure something so that these subtasks (or any subtasks) are completely ignored by Sprints. Unfortunately, I don't think that's the case. It appears that the Sprint field is automatically populated with the Parent issue's value and cannot be edited. 

[Trudy Claspill]

Hello @sgover 

I don't believe it is possible to create a configuration where the sprint closure process ignores subtasks.

The point of a subtask is that it is part of the work to "complete" the parent issue. If the subtask isn't complete then the parent issue isn't complete.

In order for the parent task to be considered complete in the sprint all its subtasks need to be complete.

Why did the team decide that making the deployment a subtask was the "right" solution? What factors of that implementation make it "right"? What factors of having the deployment as a separate issue make that implementation "wrong"?

I recommend that you separate the deployment tasks into a separate issue, not a subtask, and create a link between the original issue and the deployment task, especially if the work is owned by a team outside the bounds of the sprint and the sprint team.

[Bill Sheboy]

Hi @sgover 

Yes, and...to what Trudy suggests and asks:

For your team, it seems that "build" and "deploy" are two different work-item types, with different definitions of done, based on what you describe.  Some additional things to consider:

• are releases just-in-time or cadenced on a schedule, and
• who does the work of "deploy": the same team who does "build", a separate team, or both?

Knowing those will help the team decide how "deploy" work could be managed relative to the sprint plan/schedule.

Kind regards,
Bill

[sgover]

Thank you both for your responses! To answer your questions, the team that is responsible for the development effort is not solely responsible for the deployment. They play a part, but it is not within the control of the team. The releases are on a scheduled cadence, every two weeks, which is aligned to the development team's sprint cycle, but is not the same - they're offset. The development team's done criteria is "Ready for Deployment". It's not the end state of the ticket in Jira, but it is the end-state of the ticket for the sprint. For release management, the ticket stays alive and is "Closed" upon deployment to production. With that process in mind, it made sense to create deployment step subtasks for the deployment part of the work. However, since that deployment step subtask will always be logged prior to the sprint ending and that deployment step isn't expected to be completed until sometime after the sprint ends, Jira interprets the "Ready for Deployment" status as Done. It is, but just for the sprint. It's not done done. That doesn't happen until deployment and it's marked "Closed".

I could update the sprint board to not read Ready for Deployment as a "done" status, adding Closed to the far-rightmost column. However, that impacts all sprint reports, showing nothing ever being completed. I found another hack, within the workflow configuration for the subtask where I can label all subtask statuses as "done" states. That comes with some collateral damage, though. It might be the best solution I can find so far, given the current situation of using subtasks.

Trudy, you do bring a good point about simply proposing a new issue type for deployment step and that issue be related to the development effort ticket. I'm sure the team explored this option already, but I don't have specifics on if/why it was thrown out. I'll do some digging here.

[Emily Collins]

Good morning! I have a similar issue but slightly different reason -

I am trying to use the 'Plan' view, so that there is transparency about when things are likely to be worked on/completed, without having to interrupt the team with meetings/emails. 

The team has decided that stories should be customer value based, and as such we are finding certain stories can end up having quite a few sub-tasks, that are not necessarily achievable within a 2 week period (our sprints).

We have considered splitting the stories down even further, but it becomes quite laborious/low value to discuss and confusing to resolve later if we split certain stories purely to fit within a 2 week period to conform to JIRA limitations, and it creates complexity in the size of our stories and the customer value for each story that we would prefer to avoid.

The issue is that when we "plan" (via start date and end date) for roughly when we can address a specific subtask (ie. it might only be 1 day later) we get an error appear on our 'plan' view that says the subtask is falling outside the assigned sprint. 

Would love to have the option to:
- Assign a story to multiple sprints (if needed) 
- Remove or edit the prepopulated sprint field within the subtask (currently locked)
- Be able to "ignore" an error in the plan view for these circumstances so we don't keep checking the same thing and wasting time planning/discussing/focusing on things that are not our immediate priority.

Is there a way to do this? Or is this on a backlog somewhere? 

Thank-you so much!