In JIRA, companies manage their projects, epics, user stories and detailed tasks. Requirements are translated into concrete tickets that can be assigned and processed. Dependencies are shown here. Project progress is measured and evaluated with JIRA.
Confluence has also had tasks and task lists for several years. On this topic, someone contacted us a while ago on Twitter:
I wonder when you should use Confluence’s task lists instead of JIRA?
Good question, and one which raises more questions: Aren’t there redundancies? Isn’t it better when all tasks exist in one system? Do tasks go far beyond what Confluence can and should do? Here are my few thoughts and experiences.
JIRA tickets are structured and subject to workflows
In JIRA, a task can be much more rigidly structured and detailed than in Confluence. The author can include a summary and a detailed description, attach supporting documents where appropriate, estimate the effort needed, prioritize the task, specify a completion date, and so on. JIRA tickets are part of a specific project and they must follow specific workflows that detail which transitions they must pass through from creation to completion.
If the people in the company work with JIRA as Atlassian imagines, the current process stage is always visible for each task, including the amount of time spent on it. JIRA tickets can be found with the system search. A ticket has a unique URL. In the project’s digital agile boards, a ticket is automatically integrated.
In short: in JIRA, information density, visibility and traceability are much higher than with Confluence tasks. Simple Confluence tasks consist of some text, with perhaps a specific due date. You can’t add any further specifics or meta-information. Confluence tasks can be created and checked off. This is the entire workflow, and the only one possible. If Confluence tasks can do so little – why should they be used at all, and in what scenarios does it make sense to use them?
Confluence tasks are quick to create and practical
A task list is added when editing a Confluence page via the toolbar with just two clicks. You can assign a task simply with an @ -mention. The assignee is automatically notified by email and in their Confluence Workbox, and can directly jump to the page containing their task(s).
This is much less effort than creating and processing a number of JIRA tickets. Nevertheless, no one would (or should) have the idea to map the complex tasks of a software project to the Confluence task lists! But there are other useful applications for such simple tasks.
Tasks and further discussion points arise from many meetings. There is nothing more efficient than entering these during the meeting directly on a Confluence page, along with the meeting minutes. Here, task lists can be a preliminary step to creating JIRA tasks after the meeting. We often do this.
For Confluence-specific to-dos, Confluence tasks are useful, in my experience, especially when they concern the actual content of a page:
Theoretically, my colleagues see the page in the right context, and know at a glance and without changing tools, what to do, and can get to work. (On theory versus practice, I note a few things below.)
With us, Confluence task lists have also proved their worth for the final steps when organizing events:
We work with such lists in the same way when preparing for a trip. There is transparency and you can see everyone’s responsibilities at a glance, it is practical and easy to use for short-term to-dos – and there are enough small tasks where creating a JIRA ticket would take longer than the task itself.
There is no question: Complex and project tasks belong in the JIRA system. But where Confluence task lists are better than JIRA-tickets: They are directly in context with their content. Immediately after the meeting you can access the tasks and further topics listed on a page with their related notes – valuable and transparent. Sure, even with JIRA, you can create context using links and descriptions, but this requires additional work for the creator, as well as many clicks and system changes (context switching) by the viewer. JIRA tickets are not always necessary, I think, and it is not always possible to create them quickly. It feels strange to me to create a ticket to design a Linchpin flyer, for example. And in a meeting I can not create JIRA tickets on the fly (quickly).
In addition to the functional aspects and the applications above, JIRA tickets and Confluence tasks ownership is different. Say: Who is responsible to make sure that the tasks are actually completed (and, if necessary, also within the intended time window)?
In most software teams today, the team prioritizes and schedules its to-dos in backlog grooming sessions, sprint plans and daily stand-up meetings together with the product owner. In other teams, a project manager ‘owns’ the JIRA project. If JIRA is professionally and systematically used, there should definitely be someone who maintains an overview and takes responsibility.
This is not so clear with Confluence tasks. Perhaps a product owner or a project, team or department manager keeps an eye on all to-dos within a specific Confluence area? This is not so easy, because Confluence does not provide a task-specific search filter that you could use to regularly search for new tasks.
Here, the responsibility for completing tasks is rather with the watchers or the owner of the corresponding page. Such a list often serves as its own overview rather than organizing and structuring teamwork.
Risks and ownership
JIRA is the official project and task management system in our company. Accordingly, there is a high degree of responsibility and self-responsibility. An official JIRA ticket means that the task has to be completed (or a ticket requires at least attention and coordination). In addition, there is the pressure of your own team and your product owner or project manager, who want to have a clean, accurately documented, evaluable project.
Experience shows that Confluence tasks are subject to a greater risk of disappearing. This is where basic questions arise: Is it possible for colleagues to prioritize Confluence tasks as high as their JIRA tickets? If the tasks are so important – why are they not in JIRA?
In this respect, the creator has a certain responsibility: to assign a task to someone in Confluence and then to assume that their colleague will work on it is risky. This task flies under the ‘official’ JIRA radar. (That’s the gap between theory and practice.)
So, how do we proceed?
Probably the best advice is: If you are in doubt, use a JIRA ticket to be on the safe side – you will have the attention of the assignee. But choosing which type of task to use is a basic decision which every team and company has to make for themselves: Do we need a separate process for every (internal) small task? Do we follow the principle of no ticket, no task?
If not, then task lists are easy-to-use tools that are valuable to prompt the creation of a JIRA ticket. In other applications, they provide visibility for everyone involved as lean to-do lists, which can be comfortably checked off. With us, ad-hoc tasks in Confluence are used alongside our structured JIRA projects, without overlapping or causing other problems. However, the challenges of risks and ownership remain.