This article is going to be much less technical than the ones I use to write, the goal is to simply provide a basic introduction to Jira and some of it’s main capacities. Hopefully in the near future this article will work as the introduction on a Jira manual that my team and myself are writting for my current employeer, I thought before all that manual is finished it might be useful to share this here.

What exactly is Jira?

Jira is designed to help teams of all types manage work. Originally, Jira was a bug and issue tracker. But today, Jira has evolved into a powerful work management tool for all kinds of use cases, from requirements and test case management to agile software development.

Jira can be configured to fit any type of project. Teams can start with a project template or create their own custom workflow. Jira issues, also known as tasks, tracks each piece of work that needs to pass through the workflow steps to completion. Customizable permissions enable admins to determine who can see and perform which actions. With all project information in place, reports can be generated to track progress, productivity, and ensure nothing slips.

Currently the capacity of Jira to adapt, expand and perform tasks that it was not designed to do in the begining is starting to be mindblowing, throught the use of Plugins or simply coding a bit on top of it.

In general, I am an open-source advocate, and I had followed for years some alternatives to Jira like Taiga. But, I have to admit, until now I haven’t found any open-source solution able to substitute Jira succesfully in the enterprise context I am realizing my work (surely it is possible, but through how much effort?).

What is a Jira Project?

A jira project is a collection that holds Jira issues. Each issue in a project will share it’s project Key and a Number for the issue itself.

Beyond this simple definition, Jira projects stand alone from each other in different ways:

1. JIRA project issues will share common potential configurations. Whether they are workflows, fields, screens, etc., available configurations will be defined on a project-by-project basis based off of issue type.
2. Projects will have their own permissions system, i.e. which groups of users can access the project, which issues they can see, etc.
3. Projects will have their own versioning or release index, i.e. LEGO Castle v. 1, v. 2, etc., as well as components.

So what are the Strategies to organize Jira Projects?

There’s no wrong or right for this, but as a guideline there are some possible strategies:

1. Releasable product - If you are a software development team or a product oriented team, you might want to organize your projects by releseable product or groups of work that share a common release cycle.
2. Team - Team based projects are another common organization model. This allows your work to mirror your organization and is convenient in less cross-functional setups, as it allows for more straight forward project permission management.
3. Business Unit - You can also consider to organize around larger business units.

Other Considerations

What else can help in your decision making?

1. Components - You can still sub-categorize issues within a given project using components, this allows to organize the tasks around your project in different tasks and sub-tasks.
2. Independence - Think when work can be disparate enough to justify different projects. Requirements over time could develop to be entirely independent and justify separate projects rather than a shared one.
3. Boards - A lot of users assume that boards need to correspond to projects 1:1. This isn’t the case! Since boards are filter-based, they can map to multiple projects. Don’t let a boards restrict how you schematize your projects.

What is a Jira Workflow

Every team has their own definition of ‘Done’ and how to get there. A Jira workflow is represented on a digital board and displays the statuses and transitions of every item of work.

People has tendency to associate Jira to Software Development practices, but actually Jira is a generic Project Management and task management tool that can be used for any workflow. Let’s take some examples from the Jira website:

If you think in the tasks that you do in your daily work, probably you are able to reduce most of it (hopefully not all) to an ordered list of actions and conditionals, Jira can adapt to any such kind of workflow.

Methodologies to guide your workflow

Scrum

Perhaps the most famous of the Agile methodologies, Scrum encourages team collaboration by focusing on a single goal at a time and delivering incrementally.

A standard Scrum process begins with the creation of a product backlog, which in simple terms, is really the team’s to-do list. Each team member plans how much of the backlog he or she can complete in a given timeframe (the “Sprint,” typically two weeks). The Sprint begins and team builds the product. At the end of each Sprint, the team determines what work to tackle next based on the outcome of the previous Sprint. And the process repeats.

Kanban

Unlike Scrum, Kanban focuses on status rather than due dates. Each item of work progresses through pre-defined project stages so teams can easily see what work is in-progress and identify roadblocks.

A basic kanban board is a three-step workflow: To Do, In Progress, and Done. But depending on the unique requirements and composition of your team, additional workflow stages can be mapped in.

Jira Epics and Stories

While not a methodology per se, epics and stories are Agile artifacts to classify amount of work. An epic captures a large body of work that can be broken down into a number of smaller tasks.

Those smaller tasks, called user stories, are an effective way to write product backlog items. When utilized, they are often written from the point of view of an end users.

Or Just Create your OWN !

In reality many teams discover that just adhering to Scrum or Kanban doesn’t fits their team, Jira Workflows give you the possibility to slowly adjust and find that flow that better promotes output.