Keeping project documentation in Confluence is nothing new for most of us. With the work breakdown structure (WBS) and the Gantt chart, it is often still different: both are drawn in other tools and end up in the documentation as an attachment or an image. From then on, every change has to be updated by hand.
This time I wanted to find another way to keep both artifacts alive and maintainable. I build the WBS in Confluence as a table that links directly to the Jira work items. I build the Gantt chart in Jira, sorted by the same WBS code. Both rely on the same work items, so nothing has to be maintained twice.
My example is a project with five phases and 17 work packages. The screenshots are from a German UI, so I mention the German labels where they help. In German, the WBS is called PSP, which is why my field is named PSP-Code.
Up front: This only works with Jira Premium or Enterprise. The Initiative level above Epic and a second work type on the Epic level are only available there.
Part 1: The WBS with Jira and Confluence
My starting point is the WBS as I had it so far, as an image. From there, I create the work items in Jira.
The project is an Initiative
I create the project as an Initiative. You could put the WBS code into the summary, but in my experience it does not look good next to the work item key. If you want it there, I would put it in square brackets, like [1].
On which level should the project phases sit?
For me, this was the hardest part to think through. For a long time I assumed that the phase has to be the Epic and the work packages are tasks below it. But then I cannot treat a work package as something bigger. And as soon as a delivery team wants to create its own stories and tasks under a work package, I have a problem, because there is no room for that below a task.
So I decided to look at the phases next to the Epics. My work packages are Epics. The phases are not work themselves, they are only a way of presenting the plan, so they do not need a place in the hierarchy, only an assignment.
The work package owner is the assignee of the Epic. Below it, they create the stories and tasks they need, also in their own team's space, and select the Epic as the parent. As the project manager, I care about the Epic level, so how the work package is doing, and not about the individual steps below it. That gives me a clear line between what I need as the project manager and what the team needs for delivery.
The phases as their own work type
For the phases, I created a separate work type, Projektphasen (project phases), with its own icon. In the work type hierarchy, I put it on the Epic level and added it to the work type scheme of the space. I do not want child work items under a phase, because the level below the Epic is meant for the tasks inside the work package.
For the assignment, I created a new link type, Projektphasenzuordnung (phase assignment). The outward description is "contains as work package", the inward description is "is part of phase".
Then I create one work item per phase, set the Initiative as its parent and link the work packages. The phase shows its work packages, and the Epic shows "is part of phase Initiierung".
Milestones
I did not create milestones in Jira for this example. If you really want them there, I would handle them like the phases: a separate work type and a separate link type.
The WBS as a table in Confluence
On the project page in Confluence, I build the WBS as a simple table with as many columns and rows as the WBS has. In my example, that is five columns and seven rows. The cells do not contain typed titles but the Jira links. Confluence then shows not only the summary but also the status, and it stays current by itself. I only add the WBS code by hand. I separate the levels with cell colours.
Part 2: The Gantt chart in Jira
In the timeline and in the list, the work items are now in no meaningful order. For a Gantt chart, I need a sort order that follows the WBS, and I get it from a single text field.
The WBS code field
I create a new custom field, a short text field named PSP-Code, and give it a description of what it is for, so I still know later why it exists. The field goes on the screens of the space and is filled on every level: 1 for the Initiative, 1.1 for the phase, 1.1.1 for the work package.
The board filter
Then I change the filter of the board. The board settings show which filter the board is based on. There I replace ORDER BY Rank ASC with:
project = ABC ORDER BY "PSP-Code" ASC
Now everything comes in exactly the order I want: the project, the first phase, its work packages, the second phase, and so on. And the timeline takes over this order.
What you lose is drag and drop ranking on the board, because manual ranking only works as long as Rank is the first sort criterion in the filter.
From the timeline to the Gantt chart
In the view settings of the timeline, I show the Initiative level. Then I set the start date and due date for each work package, add the dependencies and colour the bars. From then on, each work package owner maintains their own dates.
Note: Showing Initiatives in the timeline is a feature that is not available in every instance yet. If your timeline cannot show Initiatives, you can create a separate board per project. Its filter only returns the child work items of one Initiative and sorts them by the WBS code as well:
issue in portfolioChildIssuesOf("ABC-1") ORDER BY "PSP-Code" ASC
The timeline of that board then shows only this one project, even without the Initiative row.
The list sorted by WBS code
When the dates are not the topic and I only need the order of the work packages, I add the PSP-Code column in the list view and sort it ascending. Then I see the project with its phases and work packages in the same structure.
There is only one catch: the field is text and sorts alphabetically. If a phase has more than nine work packages, 1.1.10 comes before 1.1.2. In that case I use leading zeros, so 1.1.01 to 1.1.10.
Result
I now have the WBS in Confluence, and status and summaries update by themselves through the linked work items. In Jira, I have the Gantt chart, sorted by WBS code, both in the list and in the timeline. In the project control meeting, I go through the Gantt chart in Jira together with the work package owners, and we make the updates right there. That way Jira stays the single source of truth, and the WBS in Confluence follows automatically.
