Does anybody use a "Sub-question" issue type? (As a sub-task.)

eirens

Does anybody use a "Sub-question" issue type? (As a sub-task.)

• I'm thinking about having two custom issue types:
  Question (as a primary issue)
• Sub-question (like a sub-task, but named "Sub-question" and with a unique icon).

This way I can have questions (okay, sub-questions) that are sub-tasks of a given ticket.  When I'm looking at the detail view of a sub-question, I can see the parent ticket in its breadcrumb trail up top. That's pretty nice.

Also, I plan to create a workflow so that all sub-questions (and sub-tasks) have to be in a certain completion status or resolution before the parent issue can move to a "done" state (of some kind). Not fully defined yet, but I plan to flesh this out and then do it.

Knowing a sub-task is specifically a question seems fairly useful. That way someone looking at that issue in a list, board, etc., can tell it's a question. And tasks are not questions. Queries will be better too — I can search just for sub-questions, not all sub-tasks, for example.

I don't want to use epics and issues in epics for this (though those have their own use). Because I want to be able to put sub-questions on/under any kind of issue, not just epics.

Does anybody else use this idea of "sub-questions"?

What other kinds of sub-task-type issues do folks use? Any comments?

Thanks.

Earl McCutcheon

Hello @eirens ,

I personally don't use this particular naming convention but you can defiantly set this up,  Just like Standard issue types you can create sub-task issue types for variations needed in in the subtask processes, or just a desired naming convention.

Details on setting up and creating new Subtask issue types is covered in:

• Configuring sub-tasks 

Having standard issue type = Question with a sub-task Issue type = sub-question would be useful to add seperation in workflows.  For use cases on how you could implement of having multiple task / sub-tasks issue types would be having the need for a different workflow per issue type where one workflow needs minimal inputs such as just checking something off as done like a checklist "toDo >> Done" then additional more complex workflows with extra steps or aligning to a standard workflow in the project.  And a aligning what your looking to do with a question/sub-question could be a situations where a Questions are using workflow 1 and everything else on workflow 2,  So your Question is can we do X, subtasks are a list of items to verify if possible and then other tasks like Bugs and feature requests can be handled on development specific workflows on the other issue types.  

Next for some more ideas, I would also recomend checking out the articles posted in our "Jira project best practices" guides section of the documentation as one of the points touched on in the article "How to structure your Jira project" lines up perfectly here with coming up with a good conceptual layout before getting things too complicated:

you can get as granular or as broad as you want, or you can even mix and match - just try to mirror your organizational habits and proclivities in your project setup.

AND

If your business is prone to consistent reorganization, organizing around teams and business units can potentially create a bit of headache for you as a Jira Software administrator. Merging projects and project settings can be cumbersome, so consider your organization's stability before proceeding.

There are a lot of customization options avaliable, so realistically If this layout lines up with how your org does work then it's a perfect fit for you.  However a possible pitfall is if you're using the process as something to fill a gap or shortcoming in a process you may be adding additional unneeded overhead and a better approach would be to do additional training to get teams aligned on processes.  

Also per your note on wanting to set up the following:

Also, I plan to create a workflow so that all sub-questions (and sub-tasks) have to be in a certain completion status or resolution before the parent issue can move to a "done" state (of some kind). Not fully defined yet, but I plan to flesh this out and then do it.

Check out this KB detailing the way to set this up:

• Preventing issues from being closed while the sub-tasks are still open

Regards,
Earl