Feature Request: Deliverables (Hierarchical work elements)
This is a Feature Request
for provision of a hierarchical work elements or "Deliverables" system in Gitlab, suitable for making Work Breakdown Structures. I have attempted to describe a generally-useful feature which reflects specific PMI Project Management concepts.
Executive Summary
The feature requested here is substantially similar to Milestones. It is requested as a separate feature because Milestones are logically different and serve a different purpose:
- Milestones represent arbitrary collections of activities (i.e. Issues) to complete as a unit;
- Deliverables represent parts of the final product, broken down into other parts, eventually broken down into the activities which will produce those parts when completed.
A PMI Work Breakdown Structure is created when only Work Packages (Deliverables with no Children) have attached Issues; every Deliverable is 100% represented by all of its children; and every Work Package is 100% complete when all of its Issues are closed. When a team follows this workflow:
- A Deliverable is completed when 100% of its Children are completed;
- A Work Package is completed when 100% of its Issues are closed; and
- An Issue is completed when 100% of its tasks are finished.
This feature is non-trivial; however, I believe it is reasonable, as it is substantially similar to other features and can re-use (or share) much of the same code. This is, in relative terms, a low-effort way to add an extremely valuable project planning feature without largely diverting the scope of Gitlab toward an ERP tool.
PMI Work Breakdown Structure Primer
For those unfamiliar:
- A Work Breakdown Structures (WBS) is a hierarchical decomposition of deliverables. Each element is an adjective-noun deliverable, and specifically not a verb action.
- A WBS Dictionary has a description for each component in a WBS.
- The bottom Elements of a WBS are called Work Packages.
- Work Packages further decompose into Activities and Tasks.
Gitlab doesn't have an in-built alternative, particularly because Gitlab Markdown only allows two levels of nesting:
- Level one
- Level two (two spaces) 1. Level three (four spaces)
Implementation Suggestion
I propose Gitlab include an additional "Deliverables" feature similar to Milestones. A Deliverable may have a Parent.
Each Deliverable only needs to know its Parent. This minimizes complexity: the table storing Deliverables only needs to know the single Parent, rather than the multiple Children. Children do not have multiple parents.
The Title and Description of a Deliverable (and of Issues) provide the complete function of a Work Breakdown Structure Dictionary.
As with Milestones, Deliverables may be assigned a list of Issues.
The user should have the option to display Deliverables as a tree. The simplest display is an outline view, indented at each level, with one root node. Thus levels are "1", "1.1", "1.1.1", "1.2", and so forth. Each parentless node is a major index (1, 2, 3); looking at any one Deliverable tree is like looking at an outline with one top-level element.
Usage Considerations
As described above, a Deliverable is basically the same kind of object as a Milestone, except that it may have a Parent.
A user can implement a strict PMI-style WBS by following these guidelines:
- Define Deliverables as adjective-nouns, not verbs (tasks);
- Define Issues assigned to Deliverables as Activities, which may include Tasks using the current Gitlab functionality;
- Define 100% of the work to produce any Deliverable in the total of its immediate Children;
- Only assign Issues to Deliverables with no Children;
- Only assign any Issue to one Work Package;
- Provide a Description for each Deliverable to produce a WBS Dictionary
Gitlab does not necessarily need to understand this workflow or implement strict controls. A user can assign the same Issue to multiple Deliverables, and can assign Issues to Deliverables with Children; if so, the user has not created a Work Breakdown Structure.
Any Deliverable lacking a Parent represents a separate Project in PMI terms. A single software repository can represent a PMI Program (collection of related Projects, Programs, and operational work) because separate new features, the process of assembling new features into a single release, codebase refactoring, and other discrete deliverables are separate Projects. This is a separate concept from the Gitlab "Project", which centers around the software repository rather than the definition of a unit of work.
Integration with Third-Party Tools
Deliverables described here eventually list Issues as their Activities. In PMI, Activities are things you do to accomplish a Work Package (e.g. "Interface Refactoring"), and Tasks are what Activities are made of (e.g. "Refactor Interface", "Refactor Abstract Base Class", "Refactor ClassOne", "Refactor ClassTwo"). Gitlab allows for subtasks in an Issue, making an Issue an effective Activity which includes Tasks you can just check off.
Gitlab-Kanban by LeanLabs.io displays Gitlab Issues as Kanban cards. In many Agile project management workflows, such as Scrum, the Activities of a Work Package become the Kanban cards. Many project managers will perform rolling-wave planning, describing the WBS in loose detail and then further decomposing it to work packages as work is completed and the later tasks are more fully understood, thus producing these Kanban cards.
Because Gitlab-Kanban and similar tools would only need to know about Issues and not about Deliverables, the feature suggested here immediately integrates well with such tools. Likewise, because it doesn't replace or alter Milestones, it doesn't disrupt the workflow of existing users or any third-party tool.