Mapping JIRA dates to PB Timeframe

Hey @mark,

Dates are a tricky one and I’m sure we can agree that this would be a helpful improvement to see. Looks like you already spoke with our team about your needs, so I don’t have a lot more to add here, nor clear what you’re hoping to get from this topic that hasn’t already been provided in the other discussion. It’s good to get your feedback on some of the pain this gap is causing you, so thank you for that.

In short, we currently only map custom fields in JIRA to custom fields in Productboard. So you can map those dates to custom fields (customers will often use text fields), and you would have to manually update the timeline in the Productboard timeline roadmap. Agree that’s not ideal, but it’s where we’re at currently.

The JIRA portal card has been there since 2017 as that’s the create date of the portal card -- given JIRA’s a living integration, we’re continually adding new capabilities. It’s inaccurate to state Productboard doesn’t care about the JIRA integration as it’s a widely used integration. Just some of the recent changes in the past quarter and a bit included:

• the ability to rename integrations
• the new alerts functionality that helps customers address integration issues
• new dialog flows with improved error handling
• enforcing uniqueness of release groups
• JIRA status sync’d independently of the 2-way sync
• JIRA markdown improvements including support for underline, quote, and colours in the description
• JIRA fix versions in Next Gen Projects sync’d with Productboard releases
• Reauthorization for integrations
• Unlinking of issues 

I know @Jaroslav_Tran has lots more coming on the JIRA side over the coming quarters and @Stefan and team may have some tie-ins there with our ongoing roadmap changes.

The timeline-based are great when you are trying to track progress towards a specific deadline or milestone. They are also great when you want more of a zoomed-out approach like looking at the broad objectives and roughly what you’re working on to support those objectives.

In the context of dev estimates, those estimates can often vary widely depending on the level of clarity and understanding your team has on the solution and the technical work required. Seldom are teams able to accurately nail, to a date, when the work will complete, estimates come with +/- ranges, and may flex as learnings emerge. In that case, a timeline-based roadmap probably not not be the right roadmap to use and you might be better suited to a column-based roadmap. Some teams will use both types as well -- levering a column-based to speak broadly about their efforts and a timeline based when they feel they have locked in with enough clarity to be able to communicate a timeline that they can work towards.

I think we’re in agreement that syncing dates would be helpful and something that some folks would like, but it’s not the most important one right now. And like any great product team, ours has to make the tough calls on where to focus and where not. I’ve shared your initial feedback, and I’ll leave it with them to determine when. It’s helpful to know about the challenges this causes for you and I can appreciate your desire to see the product work differently.