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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.