Sign in

New JIRA issue

  • What is JIRA?

Jira Software is an agile project management tool that supports any agile methodology, be it scrum, kanban, or your own unique flavor. From agile boards to reports, you can plan, track, and manage all your agile software development projects from a single tool. [...]

Source: Atlassian

In order to be able to filter, group, organise, assign, control our issues, we need to build a series of dependencies / precedence. This will ensure the correct allocation and prioritisation of the issue, as well as manage its logical dependency. All issues should therefore refer to a component and an epic whenever possible.

  • What is Kanban?

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Source: Atlassian

Prerequisites

Component

Under the correct project, choose the menu "Components" and create a new one. Provide at least the following information:

  1. Name: try to choose something homogeneous with the other components, and choose something descriptive enough. Some examples could be:

    • COMPONENT-service
    • COMPONENT-api
  2. Description: keep it short, to the point, quickly explaining what the component is all about. It should be fairly straightforward to derive a component name from this small description.

  3. Component lead: whenever possible, assign the component to a team member. This person will be in charge to monitor the component's lifecycle as well as its boundaries.

  4. Default assignee: can be left blank at this stage.

Issue alternatives

Epic

Consider creating an epic if you have a large user story that you want to split up into smaller chunks. You could also create an epic if you notice a pattern amongst several user stories you've created, and you want to bundle them into one group. Under the same project as the components, create an issue of type "epic" by clicking on "+" sign. Provide at least the following information:

  1. Project: select the correct project for this epic

  2. Issue type: choose 'epic'

  3. Epic name: provide a short and descriptive name:

    • knowledge gathering
    • component X
    • infrastructure
    • experiment Y
  4. Summary: provide a short summary

  5. Complexity: can be left to 'unknown'

  6. Internal priority: can be left to 'unknown'

  7. Component/s: whenever possible, link to an existing component for the same project

  8. Description: provide a short description of what this epic covers, as well as what will not be supported / included.

Story

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective

Source: Atlassian

User stories serve a number of key benefits:

  • Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users.
  • Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
  • Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
  • Stories create momentum. With each passing story the development team enjoys a small challenges and a small win, driving momentum.

Since we are using the Kanban framework, it is therefore decided to NOT use this issue type.

Task

A task is not written in the user story format. A task has more a technical nature. For example "Update Atlassian Confluence to 5.4" or "Submit app to app store". This is especially suited for work that needs to be done but is not releated to a user story, such as setting up build automation or upgrading a library.

Under the same project as the components, create an issue of type "task" by clicking on "+" sign. Provide at least the following information:

  1. Project: select the correct project for this task

  2. Issue type: choose 'task'

  3. Summary: provide a short summary. Since this is a "task", the summary should be in the form: < infinitive form of the verb > < something > (ex: implement GET route for bla)

  4. Component/s: whenever possible, link to an existing component for the same project

  5. Description: provide a short description of what this task covers, as well as what will not be supported / included

  6. Assignee: leave this blank upon creation. This will be updated during the planning/grooming phase

  7. Epic Link: whenever possible, link to an existing epic

The task should be time estimated as soon as work is started on it, in other terms, as soon as the task is dragged into the IN PROGRESS column.

Sub-Task

Sub-task issues are useful for splitting up a parent issue into a number of smaller tasks that can be assigned and tracked separately. This can provide a better picture of the progress on the issue, and allows each person involved in resolving the issue to better understand what part of the process they are responsible for

Source: Atlassian

Since we are using the Kanban framework, the sub-tasks will not be explicitlty visible in the Board(s). It is therefore completely open for developers to use sub-tasks to subdivide their tasks. This feature should however be used sparingly, as the recommended approach would be to create another "task" which is easier to estimate, allocate, and prioritise.

Bug

A problem which impairs or prevents the functions of the product.

Before reporting a bug it is necessary to make sure that the bug does not already exist in Jira.

Under the same project as the components, create an issue of type "bug" by clicking on + sign. Provide at least the following information:

  1. Project: select the correct project for this bug

  2. Issue type: choose 'bug'

  3. Summary: should be a short and precise description of the bug. It should be possible to tell what this bug is about, and where it occurs, from reading the summary alone. This is also the text that will be displayed in the list when searching for issues.

  4. Component/s: whenever possible, link to an existing component for the same project

  5. Description: this is the main description of the bug. Make sure to include at least:

    • a description of the bug
    • a very clear step by step description of how to reproduce the bug
    • a description of what you expected
    • a description of what actually happens
    • screenshots are always helpful, but optional
  6. Assignee: leave this blank upon creation. This will be updated during the planning/grooming phase

  7. Epic Link: whenever possible, link to an existing epic

The bug should be time estimated as soon as work is started on it, in other therms, as soon as the bug is dragged into the IN PROGRESS column.

Notes

Agile teams don’t need the priority field as the order of the backlog sets the priority. As priorities change within a backlog, the team remains unaffected as they are only concerned with the first few issues near the top.