Should your team put everything they do in JIRA?

Question

I have started working with a team, in a scrum master type role, who has been using JIRA for a kanban type framework. Over the last 6-12 months, they have used JIRA to enter pretty much everything they do. This includes tracking whos on call, any HR/personal tasks like training and setting personal development goals for thier people leader, regularly scheduled meetings and even days off.

My current thinking (happy to be convinced otherwise) is this is not the best use of JIRA. My rationale is it makes the board complex as they now have to have disciplined use of labels and have complex filters in order to get views that just represent the project work.

I am wrong in asking them to remove the non-project issues?

Just to add, pretty much all the team are happy to remove this stuff, it's just one particular character who is objecting.

Answer 1

Jira is a tool that aims at helping teams to manage their work. It is therefore meant to be used for teamwork. You seem to be interested in more specifically in project work.

Taking these two dimensions (team vs individual x project vs non-project) into consideration:

• Project work must be in.
• Non-project work relevant for the team could be in. Typical examples are support activities, when team is solicited after the first release to sort out unexpected problems. You could still keep them out of the selection of your kanban board, by filtering out based on the issue type. The following arguments speak in favor of keeping these in, in a kanban context:
  • the difference between non-project vs. project work can be challenging: is it a bug to be requested ? an unaddressed requirement to be developped ? or other kind of support ? So better aknowledge the task to keep a full view of the team's work.
  • having non-project support activities on the radar helps you to make the right decisions: are more people needed ? are these support activities in the statement of work / scope of the team ?
  • if these activities are in the scope of the team and you wouldn't use Jira, another tool could be needed (e.g. one of the many ITSM request and incident management tools). But then your team would have to learn an additional tool and I'm not sure that this will increase the efficiency.
• Non-project work not relevant for the team should stay out:
  • First, personal matter should stay personal (in Europe, the GDPR could even be a legal argument against putting HR stuff in a development tool; in other countries there could be other privacy regulations with same effect).
  • Then, what if a team member is moved to another team ? What with all his/her personal task: this would be an issue for both the person (not loosing the items) and the team (analysing open items to see if they are still relevant).

Holliday and other absence is not relevant for the team. It's not a task in scope. It's only use is for capacity management and this is not something Jira is designed for.

The only ambiguous point would be individual training that would be required for the project. Here you could find arguments for both options.

Answer 2

It depends on the level of visibility and traceability that your team feels is necessary.

Some of the things that you mention - on call rotation, meetings, days off - seems much more appropriate for a calendar rather than issues in any issue tracker.

Things like company related tasks and learning objectives can possibly be tracked in Jira. I can see how you can build a case that this improves visibility and may help in looking at capacity of the team.

My personal philosophy is that a Jira project equates to a particular product or service. If a team wanted to track things outside of the software product being built, I'd encourage the team to create one or more other Jira projects with the appropriate issue types and workflows, then creating dashboards and boards that pull data across relevant projects.

At the end of the day, barring any kind of compliance concerns, let the team control their tools and workflow to the extent possible.