Several months ago, we decided to change tools for managing our projects and managing incidents and software upgrade requests. We tried several products and ended up choosing Jira. I offer you a feedback on the subject.
The choice of tool
Before choosing Jira, we studied several tools to make our choice.
Our requirements were:
- manage projects
- enter times related to each task
- manage requests for corrections and application development
We tested the following software:
- Mantis ( link ): It does the job very well for managing bugs or development requests, on the other hand the time management is quite light, and the management of projects does not exist. The interface is also quite dated and not very ergonomic to use.
- Youtrack ( link ): We tested the JetBrains solution (also a PHPStorm editor that we use for our developments) which, in view of the size of our team and being self-hosted, had the advantage of being free. The interface is quite well done, even if it takes a little time to be comfortable with all the features, it is possible to do bug tracking and also project management, especially through Agile tables. Time entry was also possible and quite well done. On the other hand, we finally eliminated it because of the proprietary database, we were not comfortable not having access to the database to make requests that the interface did not offer us.
- Jira ( link ): The last software tested was Jira when neither of the two previous ones had given full satisfaction. And it is ultimately the one we have chosen for several reasons that we will explain later in this article. Let’s still retain the possibility of managing projects, being able to enter times and doing bug tracking. It also has the advantage of being able to be interfaced with numerous external software via suitable or standardized connectors, and also of being able to be completely adapted to requirements.
We started with Jira 6, and immediately came out Jira 7 to which we migrated.
Configuring a project
On Jira, you usually start by creating a project. This can be of the “Software” type (with the possibility of creating a Scrum, Kanban or basic type project) or Business (with the possibility of creating task, process or project management). Once the project has been created, you can define several things in order to best fit your organization.
Types of requests
Request types can be based on a default template, or by a template that you can define and reuse in other projects. Some examples of possible types of requests: new development, corrective maintenance, evolutionary maintenance, etc.). Note that you have the possibility to create request types also for sub-tasks (it is possible in Jira to create tasks dependent on another, or sub-task therefore).
Workflows allow you to create the different stages in the life of a ticket (open, in process, closed, resolved, etc.) and to manage the workflow between these different stages. Here again you will have a default system and you can define your own if necessary.
You also have the option to create fields in addition to the existing fields.
The components add a notion of “sub-project”. This can be useful to categorize a ticket more finely afterwards, and to have a breakdown of the times spent by component.
You will also be able to manage roles and permissions on the project through the project administration. Here again, you will find a lot of flexibility for the configuration.
Once your project has been created and configured, you will be able to create requests, which will be typed by what you have previously defined. You will need to define a demand creation strategy: do you create a demand for each basic need, do you create a broader demand (corresponding to a “brick” of your software) and then you manage by sub-tasks… This will be up to you depending on your organization and the way you are going to use the tool.
Note that you will have the following things in a request:
- a summary header with all the information on the request (title, type, component, priority, processing status, description)
- the ability to add attachments by upload or drag-and-drop
- the visualization of the persons concerned by the request, or as a simple observer
- You will finally have several tabs at the bottom of the page:
- Comments: allows you to discuss the current request. This turns out to be very practical and can even be used later to know the history of what happened on a subject.
- Work log: allows you to centralize the times entered on this request
- History: history of actions (modification, creation with before/after values) on request
- Activity: history of activities (comments, progress, etc.) on the request
- All: the consolidation of the tabs above
Requests can be exported in XML and Word format. Personally, I use this option a lot before meetings to have a summary of what happened on a request.
Then you have a rather well done request search module. It allows you to search and save your favorites as filters.
There is a notion of dashboard that will allow you to create your home page using the widgets and filters that you may have defined.
When the number of requests becomes important, it will help you to see more clearly and thus create your todo list.
It is also possible to provide a display for a wall panel.
Entering and viewing times
One of the pre-requisites to the choice was that we could enter and follow the working times per person and per project. This is all the more important since we have service providers and this allows us to reconcile this with the invoices received.
For time management, we didn’t use Jira’s native functionality, which was a bit short compared to our needs. We have installed the “Tempo” extension which is dedicated to this activity.
It is integrated into a request for entry, which makes it possible to enter the times corresponding to a task directly in it. Note that the form allowing this entry is extensible. It is also possible to define custom fields, which can be fed by a script outputting a JSONP (which makes it possible to create lists based on values located in a database outside Jira).
In our case we have created the “Activities” and “Companies” fields.
Via the “Tempo” menu, “Time sheet”, you will be able to view and consolidate the times entered. You will be able to see them by user, by team or by project.
Several types of visualization are possible:
- per timesheet
- list (as in an Excel file)
You can find all the information about the Tempo Timesheet extension on the official documentation .
Since version 7 (it was a separate module before) Jira integrates Scrum and Kanban project management.
You will be able to create tables that will be fed by a filter that you have defined (for example a table on all requests concerning a project, or a table with all bug-type requests, etc.). From there you will be able to define your sprints, sequences and versions. Requests will be able to be assigned to sprints (for example during a meeting on Monday morning). They will then be broken down according to their status in the “To do”, “in progress” or “finished” columns.
You also have a backlog with all the requests waiting to be placed in a sprint. If you want more details on the project management mode, you can read this detailed article on the subject.
Finally, you have a whole series of associated graphs (graph of progress, velocity, sprint report and version….).
Conclusion and prices
After looking at different tools, we ended up settling on Jira which completely meets our needs. We are happy with this choice so far.
In terms of prices, we started with a self-hosted model. The team is small (less than 10 users), so Jira only cost us $10 (plus $10 for the Tempo extension). If you are in the same configuration, the price is therefore not an obstacle. Note, however, that prices soar beyond 10 users Up to 25 users it will cost you 1800 dollars, and 6000 for 100. You can consult the prices page to find out more.