How to Build Marketing Lab in Jira

Have you ever struggled with organizing and prioritizing marketing ideas coming from different sides? These days, when marketing is more and more about continuous testing and extracting learnings out of those activities, it is useful to have processes and tools that support you with experimenting.

In this article, you will find a representation of a workflow for marketing tests we are adopting in our company, as well as illustrated detailed instructions on how to implement all of this in Jira.

The into image for the article, contains text How to Build Marketing Lab in Jira

Most of the companies I worked for had software development or hi-tech as the core of their businesses.

They were using Jira, but for marketing teams, it was just a tool to create tasks for other departments. To manage our marketing workflow, we chose other platforms, like Trello, which looked easier or which we had more experience with.

I can bet that this is a common situation for many companies. Sadly, such kind of inconsistency might be harmful to a company in the long run because it can lead to the fragmentation of business processes.

Now, that I am working for a company that develops apps for Jira, I’ve started improving my skills as a Jira user and have noticed a couple of ways marketers could utilize the power of this tool. In this post, I will share my approach towards building a growth marketing laboratory in Jira.

Building a Marketing Lab in Jira

One of the pillars of modern marketing is the culture of continuous testing and experimenting. There are specialized frameworks like HADI-cycles to organize this process.

"HADI is an acronym formed from the stages in the cycle - Hypothesis - Action - Data - Insights. It describes what steps an idea should go through to be evaluated."

This picture shows stages of HADI cycles: Hypothesis, Action, Data, Insights

A great way to visualize a process like this is by using a Kanban board with a separate backlog.

Ideas backlog

Before testing, any marketing idea goes to the backlog as a Jira issue. These ideas can be added by the marketing team, as well as by stakeholders and pro-active people from other departments.

It usually happens that some of the ideas might not be reasonable in terms of value for business or simply can be poorly written. That's why, before bringing them into the testing cycle, marketers need to review and prioritize them. I will return to the backlog topic a bit later. Now, let me briefly explain how I converted HADI steps into columns of my Kanban board in Jira

Testing workflow stages

In my case, I split the whole process into more stages than the HADI framework offers, but I tried to keep the spirit of it.

I also found it useful to set restrictions regarding the min and max number of cards for some steps of the cycle. This does not prevent the team from working with cards if limits are violated, but it highlights the affected column in order to draw our attention to potential problems with our workflow.

Here are the columns I use for my Kanban board.

The picture shows a kanban board with stages of marketing testing workflow


Cards with ideas that were chosen after the prioritization round are in this column.
Maximum card limit: 10 - to prevent the situation of cards staying here too long and losing their relevancy.
Minimum card limit: 2 - shows that we need to schedule a new round of backlog review to keep the process continuous.


Team members move cards with experiments into this column when they start working on them. The card should remain here while setting up the test.


Right after the experiment launch, the card goes to this column.
It is crucial to fill out a due date field to show when the experiment should have collected enough data to be analyzed.

Maximum card limit: 3 - to warn if there are too many experiments running simultaneously and to ensure that there is no overlap between them. For instance, if you enable the conversion optimization feature in Google Ads and run an A/B test of your landing page, it will be very difficult to understand what exactly influenced your conversion rate on this page.


If today is the due date of a card in the “Live experiments” column, the card should be transferred into the "To analyze" stage. Here the test waits for a marketer, or an analyst, who will take care of it.

Maximum card limit: 3 - to prevent the situation of when a team is busy with new experiments and ignores finished ones, thus losing the chance to gain new insights in a timely manner.


A card should be moved here when a marketer starts analyzing the experiment.

Sometimes, it turns out that the test hasn't gathered enough data. In this case, the card should be returned to the "Live experiments" column with an updated due date.


Before being moved to this column, the experiment should be analyzed, and the results documented. A good practice is to link your cards to Confluence pages, which contain all necessary details.

It might also be useful to add labels to cards like "Successful," "Unsuccessful," and "Failed" to mark their statuses. Moreover, you might use them to group experiments into categories, like "Traffic," "CRO," "AOV," etc. All of this will make your team's life easier when you decide to analyze your actions retrospectively.

Setting up the Jira project for the Marketing Lab

Configuring workflow

I will use the Classic project in Jira Cloud to implement my idea of a growth marketing laboratory.

So let’s choose a good name for this project and choose Kanban as a template.

A window of project creation in Jira

Right after this, I need to go to the board settings where all columns will be configured.

An arrow shows where to find a board settings option in Jira

Now, I am separating my testing workflow and backlog.

An animated visualization of how to separate a backlog from a kanban board in Jira

After this, it is time to rename the columns, add new ones, and configure the card limits for them.

If you are not sure what limits to put here, I’d recommend you begin using this workflow without any restrictions and make this decision later, when you’ve gained some experience.

Configuring limits of items in columns for a kanban board

Now, my Kanban board is configured and it is time to discuss and set up the ideas backlog.

Working with the backlog

In general, there has never been a lack of marketing ideas in any team I’ve worked with. Usually, the reverse is true and marketers need to decide which ideas need to be tested now, postponed until later, or simply thrown into the trash bin.

In order to make better decisions regarding this, I propose using the prioritization approach based on the ICE Scoring Method.

ICE stands for:

  • I - Impact;
  • C - Confidence;
  • E - Ease.

Each criterion scores from 1 to 10, where 1 is the worst and 10 is the best.

The total ICE score calculates as a multiplication of these factors:

ICE = Impact x Confidence x Ease.

Adding custom fields to your Jira cards

To prioritize my Jira backlog based on ICE score, I need:

  • 3 custom fields for Impact, Confidence, and Ease parameters.
  • A calculated field to do the math automatically.

The picture shows where to set up custom fields in Jira

For this, I need to go to Jira Settings and then, on the left-hand menu, find Issues → Custom Fields.

Here I will create 4 number fields: Impact, Confidence, Ease, and ICE.

The picture shows where to set up a custom numeric field in Jira

Creating a calculated field in Jira

Most probably, you, like me, don’t want to calculate ICE for every card on your own.

There are a couple of solutions for this. Some of them you can find on Atlassian Community. As a fresh user of Jira, I chose a different way and installed the specialized app for Jira called Abacus.

To configure it, I need to go to Project Settings → Abacus → Create a numeric formula.

Picture shows where to find formula creating functionality in Abacus

Using this add-on, I created a formula and an execution plan based on a simple trigger - Updating an issue.

The picture shows hot to create a trigger in Abacus app for Jira

Okay, now I will make those fields visible on my Jira cards. This can be configured in Project Settings → Issue Layout section.

Configuration of fields visibility on a kanban board in Jira

Another thing that makes sense is having the ICE score visible from the backlog view. Now, the team will be able to see it without needing to open every card in order to check it.

Configuration of fields visibility on a backlog in Jira

Ideas backlog refinement

Before going to testing stages, ideas should be converted into hypotheses.

For example, a card “Let’s try LinkedIn ads” is not something we can evaluate and treat as valuable for our business. The hypothesis, in this case, might read as “LinkedIn ads can bring us 100 new leads monthly,” so the card should be edited accordingly. Additionally, some ideas might be broken down into several hypotheses.

This must be done before the team goes to the next stage - prioritization of these ideas.

Marketing hypotheses prioritization in Jira

The process of prioritization, in practice, isn’t as easy as it may seem at first glance.

Estimating ideas based on three different factors (Impact, Confidence, and Ease) at the same time might be exhausting. Additionally, rating every aspect on a 1-10 scale could be quite problematic.

I’ve tried to rethink this process in order to make it smoother and easier. I came up with two rules:

  1. Compare ideas by only one characteristic at a time.
  2. Compare ideas relative to each other and then assign a numeric score, and not vice versa.

A scale which represents the idea of the relative estimation approach

So, the first rule focuses the team on one characteristic. For instance, we rate if this task is easier to implement than another task, thus we don’t pay attention to other aspects. It helps in keeping the comparison less biased.

Regarding the second rule. It is more natural for people to compare two things to each other than to operate with abstract numbers, especially if a range is quite wide, like from 1 to 10.

For example, let’s quickly compare a tennis ball and a basketball in terms of their size. Which is bigger? And now, let’s try to estimate the relative size of a baseball and a volleyball using a 1-10 scale. For me personally, the first method is much easier, and next, I will show how to set up this kind of comparison directly in Jira.

Relative estimation in Jira

Agile Poker for Jira add-on supports different types of estimation approaches. You might already have this app installed on your Jira by your software development team, if not - you need to install it by yourself or ask your Jira administrator to help you.

I will use the Agile Poker Relative session mode to begin estimating the Impact score of my ideas in the backlog.

Let’s start:

The picture shows how to start a relative estimation session in Jira

Choosing estimation scope and starting the session:

The picture shows how to select issues from a backlog for relative estimation session

After this, I move cards based on the expected level of impact for the business by comparing them to each other:

  • More valuable to the right;
  • Less valuable to the left;
  • Cards that have about the same level of impact are grouped together in one column.

It is really easy with Agile Poker app.

Animation to show the process of relative estimation

Often, as a result, I get 4-5 columns of cards.

The 1-10 scale isn’t really good for me in this case, so I use a modified range with 1, 3, 5, 8, and 10 as values. You can use the Fibonacci sequence or just a 1-5 scale. It is up to you.

I decided to use 1, 3, 5, 8, and 10 as multiplicators for ICE calculation because, in my opinion, it represents the relative difference between hypotheses well enough. Anyway, your team can change it based on what results they are getting and what ideas are in your backlog.

After defining values for every column, I save estimates to the Impact field:

The picture shows functionality of saving estimated values in Jira

Now, I need to exit to my backlog and run estimation sessions 2 more times for the Confidence and Ease fields.

Finally, the ICE score is calculated for every hypothesis in my Marketing Lab backlog.

The picture shows the backlog view in Jira with estimated ICE score

Changing the backlog order based on ICE scores

At this stage, the team needs to choose which cards will be taken to the testing cycle. In order to make it more convenient, I changed the order of cards in the backlog according to their ICE scores.

To do the same, you need to go to your Board settings and edit the filter query. Then, change the last part to ORDER BY ICE DESC.

The picture shows how to change the order of issues in Jira backlog

So, now my backlog is prioritized and I dragged items to the “TO TEST” column. As you may remember, I limited this column to 10 items maximum. Thus, 10 ideas with the highest ICE scores got into the testing cycle and 2 remained in the backlog.

At this point, the team needs to decide whether to delete the remaining cards or to re-evaluate them during the next backlog prioritization session.

The picture shows that some issues were moved to the TO TEST column and some left in backlog

You can go through this process as an independent contributor or together with a team if you have one. It works in both cases and helps to organize the workflow of marketing experiments, gain new insights, and deliver improvements on a continuous basis.

To sum up

Atlassian Jira can be configured to fit with the needs of different departments. In this article, I showed how a marketing process can be visualized and maintained with this tool. Together we learned how to:

  • Create a Kanban board for the hypothesis testing workflow (based on the idea of HADI-cycles);
  • Work with the ideas backlog and prioritize tests using the ICE scoring model;
  • Estimate Jira cards relatively using Agile Poker app;
  • Make additional changes to the project and board configuration in Jira.

Thanks for your time and attention.

You might also find the following articles useful as well:

What Type Of Estimation Method Is The Best For Your Team

Top 5 Reasons Why You Should Choose Agile Poker (over other tools) For Your Backlog Estimations