Subissues on issue board

Description

To replace our scrum board with a Gitlab Issue Board (which we really want to do), we'd need to be able to represent a user story as an issue that has sub-tasks assigned to individual people (since multiple people work on a single user story - and in many projects they have different talents: programmers, artists, UI designers, etc that need to work on specific parts of a user story to complete it together).

Different user stories have different sub-parts - and it is too error-prone to rely on people re-assigning the user story to different people during development, it is too confusing to add columns for each possible discipline (backend engineering, front-end engineering, art, audio, etc), and in many cases the subtasks can be done in parallel (which can't be represented with issue board columns).

Proposal

• Add parent-child relationships functionality to issues.
  • Parent issues have links to children issues, and children issues have link to parent.
  • Parent and children links show on the issue page.
• Completion status of the subtasks are linked to the completion status of the parent issue:
  • if the parent issue is marked complete, the subtasks are all marked complete.
  • If all subtasks are marked complete, the parent issue is marked complete.
• Child issues show on issue board under their parent issue, if in the same issue board. Otherwise child issues just appear as any other issue in the issue board.

Links / references

• #19624 (closed)
• #128 (closed)
• #4058 (moved)
• #20135 (moved)
• #17907 (closed)
• #21365 (closed)

feature proposal

I can't seem to add the "feature proposal" label to this issue myself. :-(

Added feature proposal as described in: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#feature-proposals

Changed title: Add subtasks to tasks and Issue Board → Add sub-tasks (aka sub-issues) to Issues and Issue Board

Added feature proposal ~579196 ~14281 labels

mentioned in issue #21365 (closed)

This will be a lot more useful than the current 'checkbox' method of keeping track of subtasks. It also seems like a good way to possibly distinguish EE from CE.

This is necessary to do full Scrum, and a blocker for migrating my team from a dedicated Scrum tool to Gitlab.

I guess #4058 (moved) also could serve as a minimum viable product (so that you would have to enter the issue before seeing the child issues).

We are implementing scrum in a new team who already use Gitlab. I think this proposal avoid the need of a 3rd party tool for the backlog. Gitlab seems so close to respond, it would be annoying to use a different application because of this.

Plus the possibility to view all issues accross groups (we use groups to gather app by themes), and everything would be perfect!

Thanks to think about this issue.

As we discuss about Scrum. We plan to use milestones as epics. Initially we used milestone to set sprint. But it's more convenient to follow the work with the milestone bias. The problem is, how to note sprint now? We set due date, but to use filter i think about labels. With time i will create a large amount of sprint-labels in all projects... It will be a complete mess of labels. Someone success to use Gitlab to implement Scrum in a convenient way?

I think that Epics need to be considered too to this subject. They can be an even higher level issues. Like in the thread Håvard Pedersen mention : gitlab-org/gitlab-ce#4058

@julien.legrand67

With time i will create a large amount of sprint-labels in all projects...

#19997 (closed) <-- may be helpful for you

Using milestones as epics does not sound like a good idea, since milestones are where it makes most sense to connect a date (for sprints). And milestones are generally used for releases, which sprints are. An epic might take a lot of releases to finish.

@fuzzy76 It's true, but it's the only way i found to have an easy way to follow completion of each epics. The global milestones page and the project milestones page fit well for hierarchy with a clear progress bar.

I follow differents threads here that make me think that sooner or later things will change.

Added ~874211 label

Mentioned in merge request !7499 (closed)

We're looking to implement proper SCRUM, but we're facing resistance since subtasks and Epics cannot be defined. A part of the team is looking at Taiga, Prod Pad and Jira as a possible alternative (each from a different perspective).

Given that /gitlab-org/gitlab-ee#91 is moving Gitlab towards a more scrum / agile friendly solution are there any plans to implement subtasks?

I have create a simple story board project that uses a side project to be able to present tasks:

It's a work in progress and requires some manual steps at the moment. https://gitlab.com/danielnord/gitlabTaskBoard

mentioned in issue #28431 (closed)

mentioned in issue #4058 (moved)

Assign parent issue proposal 1:

---

Child issue tree proposal 1:

---

Child issue tree proposal 2:

Note: In this proposal checkboxes are disabled and automatically checked when a child issue is closed.

mentioned in issue ux-research#2 (closed)

@florian-monfort another related issue

@mollybeth sounds like something being "evaluated", far from a stage where we can assume it will come any time soon

https://gitlab.com/gitlab-org/gitlab-ee/issues/2001 lays the ground work for this feature... but it is for EE only.

we want to just work on one type of relationship between issues for this first iteration, i.e. "related issues". In the future, we will have blocking issues and subissues.

https://gitlab.com/gitlab-org/gitlab-ee/issues/2001#note_26838779

It's not clear whether subissues should be CE or EE at this point. [https://gitlab.com/gitlab-org/gitlab-ee/issues/2001] is a building block to more advanced EE features. If or when we build any CE features that use this building block, we'll make the decision then to see whether to bring Related Issues to CE itself.

https://gitlab.com/gitlab-org/gitlab-ee/issues/2001#note_27593622

https://gitlab.com/gitlab-org/gitlab-ce/issues/31123 is going to make the issue relationships more explicit in the UI. This might lead to issue relationship management UI in CE later.

We have:

https://gitlab.com/gitlab-org/gitlab-ee/issues/2001

https://gitlab.com/gitlab-org/gitlab-ee/issues/2035

https://gitlab.com/gitlab-org/gitlab-ee/issues/2036

So making this one focused on issue boards.

changed title from Add sub-tasks (aka sub-issues) to Issues and Issue Board to Subissues on issue board