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.
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."
A great way to visualize a process like this is by using a Kanban board with a separate 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.
1) TO TEST
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.
2) SETTING UP
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.
3) LIVE EXPERIMENTS
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
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.
Right after this, I need to go to the board settings where all columns will be configured.
Now, I am separating my testing workflow and backlog.
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.
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.
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.
Creating a calculated field in Jira
Most probably, you, like me, don’t want to calculate ICE for every card on your own.
To configure it, I need to go to Project Settings → Abacus → Create a numeric formula.
Using this add-on, I created a formula and an execution plan based on a simple trigger - Updating an issue.
Okay, now I will make those fields visible on my Jira cards. This can be configured in Project Settings → Issue Layout section.
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.
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:
- Compare ideas by only one characteristic at a time.
- Compare ideas relative to each other and then assign a numeric score, and not vice versa.
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.
Choosing estimation scope and starting the 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.
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:
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.
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.
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.
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: