Jira

Introduction

Jira is a tool that allows you to organise your work across an entire company including the possibility to allow external contractors limited access. We will be using Jira as our tool to help us organise our work.

This is where you can find our Jira. Link

Below the basics of our Jira configuration are described.

Projects

Projects are generally Product based like RomeTerminal or RomeNet but can also be team based. For instance if your team is not product based but still needs its own Project in Jira. Consider well if you need one because you can combine work items from several Projects (Products) in a single board for your support team. It is advisable to have a project per product so you can easily split these up if you decide to split up in multiple teams or if we decide to drop a product for instance.
Link to Projects: Link

Boards

Boards are views on a collection of work items from one or more projects. Every team should have their own board. Teams that work on multiple projects/products can create one board that shows them the work items for both. This allows them to plan their work as a team instead of per Project/Product.
Link to boards: Link

Below you see the list as it was before we started working with Jira. One of the boards (arrow) is a team board that captures work items from 2 projects (RomeNet and RomeTerminal). This means that the RN board and RT board will likely not be used unless the team splits up into multiple teams working on just that one product.

Issue types

We have 6 basic issue types at this moment in 3 layers.

Creating issues

Here is a short intro video on creating the various issue types in Jira.

Epic

An Epic is a big user story. This is for instance a widget for rome terminal or Liquid Staking in BenQi. Usually it is a first release of a follow up release since we often have more functionality to add but the first release (mvp) already adds enough value for us to release it.
Issue Type: Level 1
Here is a link to an example Epic: Link

User Story

A User Story is the main work item type used to create functionality for any kind of user. Users should be made explisit (like first time user, returning user, RBL admin user). This helps to define the type of use case and thus the requirements. User stories are often the result of breaking down an Epic into specific use cases. For instance A search bar without filters can be useful. A second story could add a filter to the search bar.
Issue Type: Level 2
Here is a link to an example User Story: Link

Task

A task is a work item used for work that does not realise any user functionality. It might be one of three things.
1. A research task for instance something that helps you refine a user story. Example
2. An Enabler task for instance setting up a database server integrating an SDK into your product. Example
3. A task you wish to put on the board that isn't directly related to any of the products like interviewing a candidate for the team. Example
Issue Type: Level 2
Here is a link to an example Task: Link

Bug

Bugs are deviations from the intended fucntionality found after the functionality has gone to Production. Bugs should have a priority level so it is easy to decide if they need to be take care of right now or can wait for the coming sprint. You can also decide not to fix a bug at all. In that case you should close the bug.
Issue Type: Level 2
Here is a link to an example Bug: Link

Sub-task

As Sub-task is a work item that belongs to a User Story or a Task. It is a devision made for the purposes of refinement. It can also be used to make clear what work should be done by which discipline to complete the User Story or Task. In itself a Sub-task will never be pushed to production.
Issue Type: Level 3
Here is a link to an example Sub-task: Link

Sub-bug

A Sub-bug us a deviation from the intended functionality found Post-Production. It is attached to the User Story or Tasks the deviation has been found with. It should be resolved before pusting the parent work item (User Story or Task) to production. If it is decided not to fix the issue, before release to production, a Sub-bug should be changed to a regular bug. If it is decided not to fix the issue at all it should be closed.
Issue Type: Level 3
Here is a link to an example Sub-bug: Link

States

A work item (or issue in Jira) is always in a state. It transitions through these states as it gets closer to completion.

Unrefined: This means we have a name in the summary of the work item but we need to define the acceptance criteria and possible dependencies
State Type: To Do

Ready For Planning: We have cleared up the acceptance criteria and understand the dependencies, This work item can be planned for the next sprint
State Type: To Do

To Do: This Work item has been planned for this sprint but no one has started work on it as yet.
State Type: To Do

In Progress: This work item is being worked on right now.
State Type: In Progress

Review: This work item is ready to be reviewed/QA tested or is being reviewed/QA tested by a colleague (for instance design or code review).
State Type: In Progress

Awaiting Deployment: This work item is ready to be deployed to production. It has passed QA testing.
State Type: In Progress

Done: This work item is in production
State Type: Done

Closed: We decided this work item will NOT be completed.
State Type: Done

Delete: We only delete work items if they were made by mistake. If we decide we won't do the work or it is a duplicate we Close the work item.

Integrations

A list of integrations can be found here: https://romeblockchain.atlassian.net/plugins/servlet/upm

Videos and tutorials

Videos and tutorials at Atlassian are here: Link

External Users

Does your product team have non-RBL jira users? You should probably limit their scope in Jira to the products they are working with. This can be done using a Role.
Roles can be created here: https://romeblockchain.atlassian.net/secure/project/ViewProjectRoles.jspa

After creating the role it has to be used in the project's own permission scheme which can be found by going to

Project settings
Permissions
Actions
Edit Permissions

Add the Project specific Role to the following list of settings

Browse Projects
Assignable User
Assign Issues
Close Issues
Create Issues
Edit Issues
Link Issues
Move Issues
Resolve Issues
Schedule Issues
Transition Issues
Add Comments
Delete Own Comments
Edit Own Comments

You will likely have to remove access for any logged in user from all sections and add the RBL User role to all sections.

While writing this the following projects are ready for external users:

More on Project Roles: https://support.atlassian.com/jira-cloud-administration/docs/manage-project-roles/

More on Automation, creating a rule to clone all issues in an Epic when Cloning the Epic: https://community.atlassian.com/t5/Jira-questions/Is-there-a-way-to-clone-ONE-Epic-so-it-brings-over-links-and/qaq-p/796870