Ultimate Jira Guide for Large Design Teams Part 1
I think we all heard stories that “designers are not aligned with Agile development team. It’s hard to plan work for designers because there is no visibility. Design is never done and etc.” And there are reasons for that.
The goal of this article is to show the best practices of how to align designers with an agile team. It will be the first part of the series about Design Management.
Today I’m going to share the best practices encountered during my 9 years of experience. We will cover different use cases and speak about the practical approaches. As a result, you will be able to set up Jira for your design team. If you would like to focus on design management this article is for you!
Why Jira?
There are a lot of other different tools on the market, but when we speak about large design teams in big organizations, Jira is the best tool to go with. Azure DevOps is catching the market quickly because it’s a part of the Microsoft ecosystem but let’s stick with the Jira for now.
Maybe you already use different tools, for example, Trello. But the problem with other tools is that they don’t have enough functionality to manage large teams. For instance, if a design team decides to go with “simple” tools, due to lack of integrations and visibility with the agile team, problems become more crucial. Different streams might work on the same features, design teams might work on a project that is not aligned with the company’s strategy and development might not know the statuses of dependent tasks.
Features like custom issues, boards and workflows help to have visibility in the company and additional tools like Jira Portfolio and Structure help to manage everything at scale.
Let’s start with simple practices of how a design team can integrate into the Agile process. I will cover the main steps for Jira setup, but be minded that for some actions you would need admin rights. You don’t need to do everything yourself, just share these practices with your Jira Admin and provide all the needed requirements.
Custom Issue Types for Designers in Jira
I’m going to use Triple Loop Product Lifecycle phases and business goal project type. Let’s start with a product lifecycle timeline.
Above is the way Jira has all their issues on the timeline by default. Let’s take a closer look at the structure below.
When we understood the default structure, let’s improve it by adding new issue types for the design discipline. It will help everyone on the team to find the right issues and we can change their behaviour based on our needs.
We added two new issue types and both of them are used for Experience Design. Why do we have research and prototyping issues separately?
- Research activities are always high-level, without much details compared to user stories. The main goal is to validate problems, create and test various hypotheses. Main activities like user/expert/stakeholder interviews and usability testings will be conducted. That’s why it is placed on the same level as epics;
- Prototyping activities is the part where potential solutions are becoming more concrete. Since the design is much faster than the development, it’s better to store everything on the Epic level (otherwise, it is too much overhead to create design tasks for every user story). Activities like user flows, information architecture and prototyping are conducted. Every epic has a default experience design prototyping issue type.
As a result, we will get an updated timeline.
To create custom issue types you need admin rights. There are a lot of technical details that you can find on the Atlassian support website. For the majority of the cases, you can just present the structure of issue types to your Jira Admin. For example, a screenshot from this article will be enough.
Issue Fields
When we know the structure let’s cover what kind of information is needed for every issue type. There is an unlimited amount of customisation in Jira, but let’s cover only the main ones.
Description Field
Personally, here I like to provide some background information, To-Do list with some of the things that an assignee needs to prepare, acceptance criteria where a reporter can specify which kind of scenarios and edge cases have to be prepared. And finally, the resources section, where all the links to the prototypes and findings are stored.
Additional clarifications for the screenshot above:
- For the resources section, I made a separate field in Jira and integrated with Jira Automation. This way, when a sub-task is created, information from the parent issue will be inherited automatically.
- As you can see I’ve linked the review issue type. It helps to save all the communications and decisions. Inside the description field, I’m adding the meeting followup with the link to the recording, attendees list, notes, action items, decisions, open questions and resources. So everyone on the team can double-check why we started a new revision.
Due dates
In our upcoming articles, we will cover the visibility, planning and the workload. Understanding the due dates for a specific issue will help us to plan the work in the future.
Components
At this point, it’s better to discuss components with the team. From the experience, the components section can help to search and filter issues in the future. It’s like a cross-project search and can be used with the research database integration.
Side note: it is important to organize your research database properly and have it accessible for everyone on the team. The best examples that I came across so far is by Airtable. If you would like to share your set up, please feel free to do so in our DesignOps group.
Releases
We will cover the releases in greater details a bit later.
Generally, releases are mostly used in Kanban. But that’s the beginning of the next part where I will answer why Kanban is the best way to go with the design teams.
Kanban or Scrum for Design teams?
If you are not familiar with the main principles here is great documentation by Atlassian. We tried to use Scrum in our design teams and we failed, because of the following reasons:
Reason #1: Design is not the same as Development
Design can’t be compiled as in development. There is no right decision. Designers can’t estimate their efforts properly on the Scrum grooming sessions, especially for research activities. That’s why the due dates are important. It’s better to use releases instead of sprints.
Reason #2: More iterations after business, tech and user reviews
We have much more iterations than development teams. We can go through a couple of iterations with the business, then we need to make sure that everything is feasible. Then test everything with the real users and start the cycle one more time. Design teams might have more than 10 iterations for a specific epic.
Reason #3: Designers are not fully involved in development teams
Because of our speed, we are not always dedicated to one development team. We are switching between different teams and projects.
Revisions
Revisions are basically the changes to the design after review sessions. Each revision might have a couple of activities inside, which are specified in a short description as a To-Do. Because of the speed, it’s easier for design teams to specify all the scope of work in the description field and when it’s done to review all work. And if we need to update one more time we can just create another revision and work with it. Here is why revisions are the choice for design teams:
- Don’t need to create a task for each activity. Just specifying everything in the description resolves the problem with visibility and saves time;
- Easier to see that specific project or specific epic had too many revisions because the business didn’t have a clear vision;
- Easier to estimate the work that was done. If we will reopen the design issues we will need to calculate everything one more time and add the results to the total amount. With revisions, you can just estimate the work after and close it when it’s done.
Let’s take a look at our updated structure.
And to be more clear, let’s see how the updated structure will behave on the timeline.
Now we can see that before actually developing something we need to research and make sure that the solution that we are going to develop is valuable on the market. On the example above there is only one cycle with the prototyping phase and we might have much more in the future. Revisions will help you to see all the updates and find the reasons why we are making them.
Story Mapping with Releases
Story Mapping will help us to align the scope of work with the whole teams and specify the releases. More information about the story mapping can be found here.
It’s similar to the Customer Journey Map when on the top section you are specifying phases, steps or epics based on the scale of your project. Usually, it’s used for organizing user stories but I like to use it as a high-level map as well. Bellow, you can show features ordered by priority. Each of these features can become a separate epic in the future.
The goal is to divide all work into releases that we can actually release if we will not have enough budget. By making sure that the whole flow is covered and we have everything for MVP with all dependencies we make sure that the whole team understands the scope of work.
And based on estimations and the capacity that we have we can specify the releases. You can do everything directly in Jira. There are some interesting solutions on the market. But personally, for me, it’s easier to conduct this activity online with the whole team in Miro or Lucidchart.
Let’s go back to our timeline and see how releases are working for our research activities. By mapping them with the releases we can make sure that we are testing the right things for the upcoming releases.
As we know when we are doing the research activities and brainstorming on the ideas, we see how many extra features we could bring in the future. Most of the times some of them are not aligned with the business goal for the project and they are marked as our of scope functionality. It’s important to save them and for that purposes, we can use the idea bank issue type.
UX Debts and the Idea Bank
After every release, we are adding all the ideas that we had to the Jira. The best practice will be to link it to the original epic and perform the same for UX debts. For prioritizing ideas you can use GIST framework, ICE Scoring and Kano model.
You might ask why we are creating new issue types for everything when the problem can be resolved just by labels? Custom issue types will help us in the future to create custom fields, workflows and boards for the next series of articles.
Conclusion
As a result, we came up with a simple issue structure for the design teams and most importantly we integrated our design process with the agile teams.
On the next article in this series, we will start working on visibility, planning for the design teams and the workload. Will cover some of the tools for smart staffing like Jira Portfolio and will see how everything works in a real-life example.
All the best,
Farid
