How do you leverage the Jira - Productboard Integration?

  • 1 June 2022
  • 4 replies
  • 295 views

Userlevel 3
Badge +4

Hey all! How do you leverage the Jira to Productboard integration with your Product teams? We’re configuring a fresh integration right now and as we map Productboard features and feature fields onto Jira issues we’re bumping into the need to realign the definitions in each space so that we can map smoothly between the two.

How do you keep your Eng and Product teams aligned using the Jira integration, or how else do you go about it? 


4 replies

Userlevel 1
Badge +1

We’ve aligned on Productboard Feature = Jira Epic (I think this is the default guidance from Productboard docs). We’re using PB for PM/PO roles to author feature epics during strategic and quarterly planning and then push those to Jira for the team to discuss and break down into Jira User Stories during quarterly execution planning and sprint planning. We’ve not enabled this yet but we want the synchronisation to bring the Jira status back into PB by updating the Feature status (as per recent PB release).

As you’ve noticed, this resulted in some teams needing to recalibrate the level or granularity that they use Jira Epics for. I’ve guided teams to try to think of Epics as being deliverable within a “release” bucket: for us this means a quarter to align with how we present our roadmaps (Q1, Q2 etc.) This avoids features being split across release buckets in PB roadmaps. Avoiding these splits makes delivery timeframes easier to communicate although using Timeframes and visualising End Dates can help with that for longer-lived epics (if you’ve adopted Timeframes). Sometimes though, Epic delivery does split across Releases and that’s OK too.

We’ve also associated timecodes with Epics to give the team a guide to timesheet entry without making it too onerous (i.e. task level tracking). This seems a reasonable balance between allowing some estimation and forecasting of spend without chess clock tracking of time on task!

We’ve tried to phrase our Features and Components as customer “jobs to be done” (“Find a country by entering its name”) so that they don’t result in ambiguous long-lived Epics (“Search”). An exception to this is backend enablement work (“Build an index dataset of country names to feed the search”), which doesn’t suit that style.

A benefit of this approach is that the right tool for the job is used and there’s a separation of concerns between Product (build the right thing) and Engineering (build it right): the Why vs. the How, with both teams collaborating on the What. We’re not reinventing Jira with Productboard as we get to draw the line at the Epic level (using roadmap features to design and communicate our plan) whilst tapping in to Jira Engineering practices for User Story authoring, specifications, and scheduling (for us this is through Sprint ceremonies).

Userlevel 5
Badge +6

Hi @jrmatthews 

 

We actually use the Jira integration very heavily. Validity is a company which has many products which translates to many Projects in Jira and different processes for each. One great thing about the integration is that you can setup different Jira Integrations for the same Jira instance so what we have done is setup a Jira integration per product in PB (Project in Jira) which has its unique nuances, mappings and structures. 

 

The way I use the integration for the Products I manage is as follows:

  • Jira Epics are used to group a stream of work so as @craig.foot mentioned the recommendation from Product board is a Jira Epic maps to a Feature and then all tickets related to the epic will be sub features in Product board. Product board has recently released quite a lot of improvements on the management of sub features which is really cool for individual planning.
  • Now in saying the above not all story/tasks/bug etc map to an Epic in Jira so for the tickets that do not map to an epic we just have them as features. 
  • I have also enabled the sync from Jira Project to ProductBoard Product which creates a feature for every ticket created given a set criteria. This saves me so much time in trying to keep the 2 in sync
  • I then use components to Group areas of the Product. One of the products I manage is a web application (GridBuddy Connect) and it has 3 groupings of pages which are used to defined the first layer of the component hierarchy. From there I then have created a Component per page within each of the groupings and then the features sit underneath that
  • I also strongly suggest enabling the status mapping functionality that automatically changes the Productboard feature status when the Jira status changes. Massive lifesaver for me 
  • We also enabled the sync of releases to release groups in PB

 

Some things to look out for when enabling the jira integration:

  • Make sure to map Jira Statuses to different colors, this helps differentiate tracking quite a lot
  • Create a Release Group in PB per product before starting your sync
  • Make sure to map the correct effort field to ProductBoards Effort field
  • Be aware any change to a feature will automatically sync back for example if you move a sub feature to be a feature it will loose its epic link
  • Do a one time import of all your existing OPEN tickets but make sure you review them before importing in the preview screen. Its important that you apply the correct filters to the Jira Query you use so that you don’t pull multiple projects worth of tickets into the one PB Product

 

Hope this helps

Userlevel 3
Badge +4

Wow, @craig.foot @Andrew Fragias, thanks so much for the input here!

 

Craig, love the incorporation of the jobs-to-be-done framework into your hierarchy structure.

 

Andrew, curious about the effort mapping you mentioned between Productboard and Jira, I’m not sure I realized you could map from Jira onto the PB effort field?

 

So much for me to chew on, thanks all. 

Userlevel 7
Badge +13

@jrmatthews this support article has the details on mapping custom JIRA fields to Productboard 

Reply