Getting Started With JIRA

When I was born, my parents looked each other in the eyes and said "this kid is going to grow up to write detailed documentation for software products too complex for our current generation to fully understand." Boy, were they right.

Perhaps you've just started diving into JIRA. In that case, the first glance at its bland aesthetic and stark UI elements probably set off the PTSD you acquired from your fluorescent light cubicle days. Or you may be an experienced director, and you're excited to share your methods of software development with your company.

Regardless of who you are, JIRA is arguably the best software development management tool in the market. You're in good hands, so let's take a deep breath and get your bearings in JIRA.

Find Your Project

JIRA is separated into "projects" as your organization will work on multiple projects throughout its existence. We'll assume an admin has created and invited you to a project.

Logging in lands you on a general dashboard. This is a summary of all recent activity in your JIRA instance, but isn't too important. At best, it provides you with an overview of recent activity.

Navigate to the project you've been invited to by clicking into the “projects” drop down menu. If you aren’t seeing your project, try clicking “view all projects” within the same drop down.

Viewing a Project

A project should serve as the Bible by which PMs, Developers, QA Testers, and occasionally clients of the project abide to.

A project is a made up of the work (issues) which need to get done, moving through time (sprints).

There are multiple ways to visualize this concept of 'work over time'. The tabs in the left sidebar represent different ways of visualizing the project:

Backlog: The “backlog” view consists of not only a backlog of issues for the project, but rather all issues and sprints which have yet to be released.

Active Sprint (Board): This view only displays issues in the current sprint, and depicts where each issue is in the development process.

Reports: Project charts visualize team progress, and the likelihood that target dates will be hit.

Issues: In contrast to the backlog which maps remaining work, the issues tab is an interface to browse all issues of a project, regardless of time or completion.

Project Backlog

The backlog is most useful for planning what remains to be done in the project, and is perhaps the most essential.

Below is a backlog of “issues,” which are 'things which needs to be done'. These issues are grouped into sprints, which are iterations of the product over time. Sprints typically denote milestones, such as a demo or release of the product.

When a sprint is closed, its completed issues are archived from the backlog view and are no longer visible. Issues left incomplete at the end of a sprint may roll over to the next sprint.

Issues & Issue Types

Each issue has a 'type' which represents the nature of the task.

Standard issue types include:

• User Stories: A feature of the product described from a user’s perspective
• Tasks: A general task which needs to be completed
• Bugs: Unintended flaws in the currently existing product
• Epics: Technically not issues themselves, but rather a larger collection of related issues

Examples of non-standard issue types that I personally like to use:

• Frontend Task: A frontend-only task
• Backend Task: A backend-only task (usually associated to a FE counterpart)
  Module: An encapsulated widget to be reused across a product
• Page/View: A ‘screen’ of a product (usually relevant for module-based projects)
• Idea: A backlog item which may potentially be pursued, but has not been fleshed out yet

JIRA allows admins to define their own issue types. A good JIRA admin should restrict projects to only using issue types which are conducive to what is being built (for example, user stories are not a good way of representing projects which are entirely static content).

Issue Details

Expanding an issue will expose the full details and requirements. Attributes of an issue include:

• Issue Type: Nature of the issue.
• Priority: The level of importance.
• Epic Link: The family of issues, used to group tasks together into pieces of the product.
• Sprint: Iteration scheduled for completion.
• Status: Working progress of the issue.
• Resolution: Reason for completion (ie: can’t reproduce, won’t fix, etc).
• Assignee: Team member responsible for addressing the task.
• Reporter: Team member who created the task.
• Time Estimated: Original time estimated for completion.
• Time Logged/Remaining: Time spent on the task as well as time remaining.
• Description: Requirements.
• Comments: Conversations between team members.
• Labels: Custom tags, used almost exclusively for search purposes.

Boards

When a project is underway, the current sprint is considered an “active” sprint.

Boards are a representation the active sprint, visually measuring the progress of work. Issues of the sprint move through phases of completion in a standard Kanban workflow.

When a sprint is complete, all issues marked as “done” will be archived. All incomplete issues will either be rolled over to the next sprint, or sent to backlog based on the PM’s discretion.

Note: These columns can be customized by an admin to represent the ideal workflow per project.

Browse Issues

All issues associated with the project. "View all" mode has a filter which allows users to filter through all past and present issues.

This is useful for solving the following common use cases:

• View a list of all completed tasks for the project thus far.
• See how many modules, pages, etc this project consists of.
• Find an issue which was mistakenly marked as resolved.
• Export issues to a CSV for reporting.

Why JIRA?

Managing a product between multiple tools is hectic. Keeping everything in JIRA ensures that information is organized in a single place and hard to miss.

JIRA surely has its faults, but I've personally found the pros to outweigh the cons against comparable software in the market:

Pros

JIRA is clearly focused on software development above all else, which offers many benefits to dev teams:

• Scope vs Time: High emphasis on time as a factor in software development.
• Estimation: A streamlined process for estimating level of effort and tracking progress.
• Charting: Visually track progress against schedule.
• Centralized History: Avoids repetition, reduces meetings, and creates accountability.
• Issue Linking: The ability to specify complicated relationships between issues.
• Customization: Dictate processes based on the nature of each project.
• Querying: Easy to sort issues on large scale projects (compare this to specification documents or less powerful tools).

Cons

• Old Guy at the Party: JIRA has been around for a long time and has some convoluted admin-related processes which make little logical sense. The JIRA we use now is clearly the evolution of a legacy system. Feel free to watch this 5-minute tutorial on restricting user permissions. Yeah, it’s really dumb.
• Not Trendy: Trello has a talking husky named Taco; that’s pretty neat. Using JIRA looks and feels a lot like you’re working, probably because you are. The majority of enterprise dev shops use JIRA, and nobody wants to feel like one of those guys.
• You Gotta Know What’s Up: Agile, waterfall, Kanban, scrum, blah blah blah. Everybody knows the buzzwords, but few understand how to actually execute effective agile software development processes. To use JIRA effectively, you gotta know what’s up.
• It Takes Effort: Nobody likes reading, writing, or managing requirements. It takes time, and it’s not as fun as hanging out in Slack. It seems that way at first (which is enough to dissuade most,) but when deadlines are at play a centralized project bible can be the anchor that saves a team of friends from implosion.