There are dozens of popular tools currently being used to help manage Agile projects. For managing tasks on large or complex projects, however, JIRA has proven to be a more useful tool than than Trello. This is for a number of reasons, which are not limited to the following.
Perception versus reality
There are some perceptions that need to be addressed before JIRA can be embedded into a team or department that have been using Trello successfully, but are unaware of its limitations.
|Providing Detail||JIRA is more work as more information is required. Developers should be coding, not adding information to tools.||Many JIRA fields are optional and can also be hidden. However, most of the information should be provided in any tool or repository to improve planning, transparency, tracking and team collaboration.|
|Interface||Trello has a much better interface and custom backgrounds. Everything is in one screen.
JIRA has lists and is confusing.
|The dreaded list view is optional. Developers are only required to view three JIRA Agile screens:
1. ‘Scrum Board > Active Sprints’ – during a sprint;
2. ‘Scrum Board > Backlog’ – during sprint planning and backlog refinement;
3. Issue Edit – to view, edit or transition an issue (task).
Other screens are optional, but useful to advanced users and stakeholders.
JIRA is most useful when it is fully configured to how a team want to work, i.e. how they want to manage tasks and defects. In the project below, issue types, workflows (statuses and transitions), a Scrum Board (swim lanes and columns) and the Issue Edit screen were fully configured to the project team’s requirements. For reporting, numerous filters were created to feed into Dashboard Gadgets.
The Agile Scrum Board was configured to reflect the physical task board (used in daily Scrums) and the statuses created on the complex workflow (see below). Assignee swim lanes were configured to easily see who was working on what, as with the physical task board.
Multiple Epics were created to reflect the major task groupings of the project on the Scrum Board Backlog.
The issue editor was configured to hide fields that were not required until the later stages of the project, e.g. Priority, Affects Version, Fix Version, etc.
The workflows enabled the series of activities required to complete a task to be easily stepped through and adhered to. A simple and complex workflow was created for non-technical and technical tasks respectively.
|Simple Workflow – Non-Technical Tasks||Complex Workflow – Technical Tasks|
|1. Standard Task
2. Standard Sub-task
|1. Story or Defect
2. Technical Sub-task
Finally, filters were created for each task grouping and Sprint to utilise Dashboard Gadgets that are refreshed at regular intervals. The use of JIRA Dashboards will be covered in a separate post.
In summary, when configured fully, JIRA is a very powerful tool for managing large and complex projects. Once a configuration has been used successfully for one project, it can be easily copied and tailored to other projects. However, to avoid months of trial and error, we recommend an experienced JIRA administrator, who has previously configured and used JIRA in anger to deliver various projects, is brought in to efficiently configure JIRA to your team’s requirements.