0

Background & Objectives

Atlassian JIRA is really just a ticketing system at heart. While there are a number of agile-ish workflows and plugins available to the system, the fundamental design of the tool is to enforce assignment of tickets to individuals rather than groups.

From an agile perspective (and specifically from a SAFe 4.5 perspective), I would much rather see issues assigned to affinity groups than individuals. Actually, I’d rather see them assigned to product queues rather than teams, but that may be a step too far for the tool.

Atlassian offers several kludges for trying to work around this issue, but they all feel a bit...well, suboptimal. Even the “Unassigned” queue or the custom group picker option seem to require bypassing a large number of built-in reporting and tracking capabilities of JIRA, and I don’t want to recommend a workaround that results in reduced value from other standard features of the tool.

The Question

How can I most effectively use JIRA to communicate the values of collective team ownership, pairing, and swarming within JIRA without making it impossible to use the standard dashboards and reports?

Caveats

  1. Tool selection was a business decision above my pay grade. I can’t enforce CodeGnome’s Law or First Corollary, and have to do my best to work within the tool’s constraints.
  2. I’m really looking for a process answer, but workflows, practices, JIRA plugins, or custom reporting are certainly within scope.
  3. I want to be crystal clear that I’m looking for a framework-centric solution that takes the tool limitations into account, rather than seeking software recommendations.
Improve this question
6
  • What do you mean under "assign" term? Task is eventually assigned to an individual and JIRA does not allow group assignment or group work (one, however can log the work for the task assigned to another). Doesn't Jira scrum board address your needs?
    – Alexey R.
    Commented Jan 30, 2018 at 17:49
  • @AlexeyR. JIRA does allow some kludgey alternatives to individual assignment, which I linked to in the question. But if you read the Confluence document, there are a ton of gotchas. Individual assignment is fundamentally a non-agile smell, though.
    – Todd A. Jacobs ♦
    Commented Jan 30, 2018 at 17:58
  • Why is having a single person accountable for progressing work a "non-agile smell"? I agree that pairing or mobbing is good, and if you use these, it should come out in your iteration planning activities (the amount of work you take on with heavy pairing or mobbing is less than individuals doing work and then submitting for review and pairing as-necessary). But I've found that if one person is not identified as accountable for the work or made responsible for making sure progress happens, it's less likely to get done. You can add custom fields to identify people in pairs or mobs, if you must.
    – Thomas Owens ♦
    Commented Jan 30, 2018 at 18:35
  • @ThomasOwens Because the whole team is accountable. Even if the team has a non-fluid approach to story ownership, as an information radiator the whole notion of individual “assignments” (esp. push vs. pull) often leads less experienced teams and organizational management to structure around individual utilization and individual assignments rather than pairing and swarming. In my professional experience, the underlying metaphor of the tool often drives the process in myriad subtle (and not so subtle) ways despite best intentions.
    – Todd A. Jacobs ♦
    Commented Jan 30, 2018 at 21:42
  • 1
    @ThomasOwens One person accountable is team destructive.
    – Alan Larimer
    Commented Jan 31, 2018 at 12:56

4 Answers 4

Reset to default
1

I would avoid using ticket assignment for this purpose. Typically, I've seen the Assignee is unassigned until a development team member picks up the story/task in sprint. This may differ at the feature/epic level as the product management team refines the backlog.

It is very common to use the Labels field and add a team name when the feature/epic/story is assigned to a team. It's then quite easy to create team-oriented Boards that filter on the team name. This filter carries through to the Backlog and Reporting tabs so you can plan or analyze by team.

Hope this helps!

Improve this answer
1

You could create JIRA users that represent groups.

The key bit of information in a JIRA user is the email address, so all you would need is email aliases that represent mailing lists for each group.

This would mean that an issue could move through its life cycle and never be assigned to an individual. Notification would still work as all members of an assigned group (or product queue) would receive email updates.

The down side with this approach is that you would need to ensure you kept the membership of the various mailing lists up to date.

Improve this answer
3
  • I saw this option in the list of "official" kludges. Other than the overhead of mailing list maintenance, does this cause any other major headaches with reporting, state transitions, or other core functionality? It certainly seems like the least-worst of the published options.
    – Todd A. Jacobs ♦
    Commented Jan 31, 2018 at 11:09
  • My biggest concern with this approach is that if you are not familiar with the project and the team makeups it is difficult to determine who to talk to about a particular issue. I quite like the idea of using metadata on the 'group' user that indicates who is in the group and then displaying it in issues as a custom field. Never tried to get that working though, so I'm not sure if it is possible. Reporting shouldn't be a problem, unless you need to report at the individual level.
    – Barnaby Golden
    Commented Jan 31, 2018 at 11:53
  • 2
    I'm actually trying to steer the organization away from trying to report at the individual level. While I fully support continuous dialogue between the team and stakeholders/end-users around in-Sprint work (because "collaboration"), individual attribution of work isn't an information radiator about work, but about utilization or a proxy for individual performance. That's the anti-pattern I'm trying to avoid. Your points are well taken, though!
    – Todd A. Jacobs ♦
    Commented Jan 31, 2018 at 11:59
0

What value of the "standard dashboards and reports" is impeded? Is, or why is, not assigning the object to an individual an option? (What is the root issue/concern/motivator?)

When dictated to use tools, or even when using selected tools, promoting the team mentality is easily supported by simply removing the requirement for that field to be populated. (I haven't used Jira in a while, so maybe it is not possible; it is possible in VSTS, for example.)

Improve this answer
2
  • The Confluence post in my OP lists some workarounds including not requiring assignment, but setting Allow unassigned issues is global, and would affect more than just the agile projects in JIRA. That approach also wouldn't promote team accountability; it would just treat all work as a queue, which could be useful in Kanban, but seems less so for Scrum or SAFe.
    – Todd A. Jacobs ♦
    Commented Jan 31, 2018 at 12:04
  • How does not assigning an item to an individual not promote team accountability? Perhaps clarification of what team accountability means to you would be helpful in revealing the issue/concern/motivator. If there are multiple teams working on the same product and distinguishing that is the issue then that could be clarified in the question. The Product Backlog as an ordered list is a modifiable queue and Sprint Backlog belongs to the self-organizing Development Team; no problems there. Sharing a Jira instance with others also seems to be an issue due to the global setting concern.
    – Alan Larimer
    Commented Jan 31, 2018 at 12:53
0

I believe the problem is (as Alex notes) the tool itself was not designed to specifically address SAFe. Built-in's and workarounds added try to make up for it.
Have you looked at integrating other tools into JIRA to give you what you need? Not saying to replace JIRA, but add value. Tools like SwiftEASe from Digite provide a tool that can be used as a standalone SAFe implementation tool or fully integrated into JIRA resolving many of the problems you noted.

The problem you are having in a nut shell - lipstick on a pig.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.