Jira Configuration and Usage

To allow our choice of Jira to support not just the immediate need for small groups of people to work on Building Blocks, Use-cases and other matters but the intended welcoming of a wider group of people from all backgrounds into the project, we need to place a consistent structure into our configuration and usage of Jira. 

How do we define areas of work? 

GovStack has multiple areas of work, each with a lead person responsible for that area of work. Let’s call them Teams. 

We will create one Project for each Team – so, that’s one Project per Building Block, plus one for the Product Committee, the Technical Committee and the Governance Committee. There may be one or more working groups, such as Comms; they also get a Project. 

Everybody has access to all these Projects, unless there are specific privacy needs to restrict access based upon the data classifications agreed by the project. 

How do we define pieces of work? 

There are two main ways to define pieces of work; as small requests to complete a task/bug or more impactful, “planned” work. Examples of planned work would be to complete a building block technical specification chapter or to publish a release of the building block or even the overall specification.   

Planned work 

While all work can be associated with sprints and given timelines, we will generally plan our work using Epics in Jira. 

An Epic must describe (can we make the template Epic have these questions in it?) 

• The purpose of the Epic — what we intend to achieve 

• Once scheduled, a start date and estimated completion date 

• A clear definition of done — how do we know if the Epic has been completed 

• A measure of the expected complexity of the work. T-Shirt sizing is a good, simple way to track this (ie Small, Medium, Large, XL) 

• A person responsible for delivery 

An Epic will usually reference several Tasks that describe and manage all the steps necessary to deliver the Epic. Each Epic should have a specific focus area, usually related to some specific functionality or work stream, and should be able to be accomplished within a single release cycle. For long-running (that is, longer than a single release cycle) or repeating sets of tasks, individual Epics should be created to limit the overall scope. 

Epics are usually defined and managed by the lead of the Project in which they live. 

The roadmap for each Project is a timeline display of all the Epics.   

Small requests to complete a task 

We will use Jira Tasks for all small, defined requests of work. A Task may be part of an Epic or exist outside of the planned work and not be related to an Epic.  

An example of a Task could be a Task from the Product Committee to create this document, as per PROD-8. It is a standalone piece of work required to support the project, in the Product Committee project, but not part of a planned piece of work as described by an Epic. 

A Task must describe: 

• The purpose of the task — what we intend to achieve 

• A clear definition of done (acceptance criteria) 

Note that a task does not necessarily require a start/end date. Those may sometimes be useful but timeline planning should take place at the Epic level as that is what is represented on the roadmap. Estimates can be made when a Task is assigned to an Epic and is ready to be worked. 

Anyone can (and should) feel empowered to create Tasks in the project, even (especially?) those new to the project. 

To work on a task, simply assign it to yourself and update the status. While tasks can be assigned to others, this should generally be done by the team lead or after agreement with the assignee. All work updates and discussion should be recorded as comments on the Task, with the exception of long-form documents which can be created in Confluence and then linked to the task. 

The lead of each Project is responsible for reviewing all new Tasks at least bi-weekly as part of a backlog grooming process. We suggest the best way to do this is in weekly team meetings, to involve the wider team. 

How do we monitor progress? 

As mentioned above, all of the planned work in all of the Projects is defined in the Epics. So, we simply need to use the roadmap view in each Project, that displays all the Epics against a timeline, including their status. 

To aid the leads of each Project, we should also create a Kanban view of Epics and a list view of all new (as in contain no comments on progress) Tasks. These then for the basis of the progress updates at weekly meetings. Any decisions on the Epics or Tasks examined should be added as comments to the Epics/Tasks themselves.