UX team using Jira - How to do iterations, have multiple assignees and exploratory work

[Alexandra Wayne Harper]

My name is Alexandra and I am a PM for a UX Platform Design team. I was hoping to connect and pick your brain about some issues that have come up with my team's integration into Jira!I just introduced Jira to my team and I am trying to make it worthwhile for my creative team. I had a few questions for you that go against the normal Jira setup and I am wondering how you may have solved these issues on your teams!

1. How do you work with iterative tasks across sprints? I often have work that is either recurring or has many iterations. What are the best practices around this? I know if you are constantly moving tasks from sprint to sprint it can affect the data. Overall though, I don't want to have to create a million tasks to link together per sprint.

2. A lot of the work we do involves more than 1 assignee. Have you bumped into this on your team? I would love to hear any workaround you have or ideas!

I see that you can create a multi-picker field in Jira to accommodate for this but my organization said that can get messy over time. They told me to add 1 assignee and the rest as watchers. That could work but I would need to figure out what kind of filter to create for the swimlanes on my board. Any ideas on this one? I know it is best practice to break the work down into tasks small enough for 1 person but it is actually causing a lot of extra work.I hope to hear from you! Thank you so so much in advance!

Warmly,

Alexandra

[Bill Sheboy]

Hi @Alexandra Wayne Harper  -- Welcome to the Atlassian Community!

Several of the questions you have are common to service-oriented work in silo'd orgs (like UI/UX, architecture, dev teams, etc.).  This may be regardless of whether the people doing the work are on a stand-alone team like yours or embedded on delivery teams.  Please consider:

• When using a stand-alone service team model, it can be difficult to align your workflow and cadence to the client teams (e.g. dev teams).  For such cases please consider using Kanban rather than Scrum to manage your work, and create a defined "intake process" for partnering with the clients.  Thus UI/UX work wouldn't need to be split up based upon client team iterations/sprints, keeping requests as complete and valuable chunks.
• For service team people embedded with client teams, like in the SVPG models from Marty Cagan, you may need two workflow levels:
  • one aligned to how the client team works (Scrum, Kanban, etc.) and
  • a separate Kanban workflow for any enterprise-spanning work the UI/UX team does (e.g shared assets guide, field experiments, etc.)
• Regarding multiple assignees, Jira assumes one assignee, or lead on a work item.  Others may collaborate on it.
  • Some Jira users implement the work-arounds you note (e.g. a custom field for Additional Assignees), which can lead to accountability and other issues
  • If your work in progress (WIP) count is low, this is less of an issue: re-assign work when it has a new "owner" and otherwise collaborate on the in-progress items
  • When you need to specifically account for *everyone* who helped on a work item, consider one of the work-arounds...after first considering how to reduce WIP.
  • If you try one of the work-around for multiple assignees, you may consider quick filters to help with boards and issue visibility, looking at both Assignee and any custom fields used to note all participants.

Best regards,

Bill