+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?
+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).
+6
Hi
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:
Some things to look out for when enabling the jira integration:
Hope this helps
+4
Wow,
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.
+13
You can create an account below using either single sign-on or a username/password. Already have an account? Login.
No account? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
