Skip to content

Jira Guideline

This guide explains how we use Jira.

Methodology adapted to our team

We do not use Jira and standard types for traditional Agile project, but we have defined our own methodology for our team.

Terminology

We use 3 types of tickets with Jira.

  • Epic to define a relatively consistent work theme
  • Story to define a feature or a functional improvement
  • Bug to define an official bug identified in a version
  • Task to define a technical activity

Epic

Epics are significantly larger bodies of work

Epics are simply containers that are filled with user stories and track details for a particular body of work.
Use them to capture large pieces of work, provide a high-level description of the work that will be done.

When is the epic identified ?

Whenever an element enters the backlog, we first decide to qualify it as an epic or as a story.

Use of epic

  • It is forbidden to enter an epic in the backlog.

  • We can change our mind: a story can become epic and vice versa, why not.

  • Once the decomposition is done, the epic disappears, only the stories remain.

Story

A Story, or Story is a feature or functional improvement you want to realise.

Content of a Story

  • A description of the need
  • A definition of the acceptability criteria.
  • A good User Story must also respect the characteristics gathered under the logo INVEST:
    • Independent: ensures the independence of a User Story vis-à-vis the other user stories of the backlog;
    • Negotiable: a User Story must be a discussion support for an improvement of the initial need;
    • Valuable: the realization of a User Story must render a service to the user. In a nutshell, a User Story only makes sense if it brings business value;
    • Estimable: a User Story must be well defined to be easily quantifiable;
    • Sufficiently small: a User Story must be feasible on a sprint;
    • Testable: a User Story must be accompanied by these acceptability criteria to facilitate its validation.

Task

A task is something that should be done, without much complexity or discussion involved.

A task does not introduce new feature, does not fix a bug.

Because code quality result from continuous improvements there are many tasks.

Bug

A Bug is a type of ticket that identifies an official malfunction of the product.

It can be created by the support team, or by the development team

Create a bug ticket in the following cases:

  • following a support incident
  • following a bug in a released version (dev)

A bug appeared during a dev of an unreleased version is not considered a bug.

Find original ticket treating a dev and improves dev.

Fields of forms

Summary

Short and precise summary. English only

This sentence will be present as is in the release note. It must be clear and concise.

Components

The components are defined macro parts that cut the software.
Select at least one component that best reflects the subject.
The components are not labels / tags. The list is predefined.

 Component  Keywords description Example
build Gitlab, Maven, pp-packaging...  When you move files in pp-packging, or fix CI
core pp-core, pp-grok  When you code in Java
 deployer  Ansible  When you change deployer
 documentation pp-doc  When you update documentation
expertise Parser  Expertises activities
gui pp-gui  GUI development
metrics metric Everything about metrics
 monitoring dashboard  Everything about monitoring
 security modsecurity, Keycloak, tenant Everything about security 
testing unit test, env validation... Test campaign and release, Bench...

Description

Description relatively complete. Ideally by specifying the context and the expected.
Can be written in English or French, for convenience.

The expected is important.

The expected set a concrete target and validates the successful completion of the ticket

Fix version

Fill in this field only when you have processed the ticket, specifying for which version the changes will be available (usually the next minor version).

Affect version

Fill in this field only in the case of a Bug to estimate since when the error exists.

Priority

Priority of the ticket, based on the examples of priorities below:

  • Highest (Blocking)
  • A bug causes the loss of logs
  • It is not possible to run topologies
  • High (Desired)
  • Add "how lightopo works" into the documentation
  • elasticsearch logs are not rotated
  • Medium (Default)
  • Default no opinion on the matter.
  • Majority of topics that begin with "Improve..."
  • Low (When I have time)
  • Deprecation warnings in Ceph REST API
  • Lowest (Nice to have)
  • All topics that begin with "It would be nice to do..." are by default on this priority.
    When the subject becomes a priority, it will be edited to match a real request

Update documentation is as important as new feature

Assignee

Avoid assigning the task in advance, or assigning someone on it. Because this task will remain blocked until the assigned person realizes it.

Prefer to assign yourself when you start the task to inform others who realizes it

Do not reassign the task, use the naming @collaborator in the comments and / or description to include other user actions.

You are thus the only one to decide and follow in its entirety the state of the ticket.

Sprint

Ask the sprint master to add the ticket to the current or next sprint.

Original and Remaining Estimate

No used.

Labels

Labels can be anything. We use labels to make issues more searchable. Labels allow us to tag jira tickets with more than one category.

Warning

this said do not create label on your own, adding one more personal logic to the game.
Defining lables is a team decision.
In short : check with the team first.