Productboard & Azure DevOps Integration 2-way sync (Title, Description)

I am having a really hard time creating a sustainable process with Productboard, if the only two pieces of data that is linked bidirectionally are:

• Productboard Feature Name <> Azure DevOps Work Item Title
• Productboard Feature Description <> Azure DevOps Work Item Description

That is the absolute minimum, but it is certainly not enough.  What happens when I move something from one sprint to another, or pull something out of backlog into a sprint planned a couple out?  Am I really going to have to make the change in BOTH Productboard and in DevOps?  I must be missing something here. I would think this would end up being a requirement for anyone’s process when trying to use these tools together.  

Thoroughly confused...

Shawn

Hello @Jaroslav_Tran ,

I am looking forward to this improvement. Is there somewhere that I can track the progress of this in your Productboard?

Best,

Pouya

Hello @shawnmcady 

Regarding Automating Feature Status Updates from Azure DevOps to Productboard, it should be released by the end of this month. 

Unfortunately, apart from that, there are no planned ADO improvements in Q3. Syncing iterations or sprints is not something that would be high on the priority list atm. When we start working on the ADO improvements, we are more looking into supporting sync of attributes such as Date/Timeframe, Member Fields, Numerical Fields, Dropdown Fields, etc. 

@andyjohansson the Shortcut integration was built by Shortcut, not by Productboard, so that would be up to them to determine.

Issues like this are what keep Atlassian alive, despite the last several years of gross negligence. Solutions like AzureDO and Shortcut just aren’t viable until the associated integrations actually work in practice.

@shawnmcady FWIW, I believe AirFocus’ ADO integration is more feature complete. I think their solution is weaker in other areas, but it might be worth looking at if the ADO connection is critical for your workflow.

@Jaroslav_Tran thanks for the update earlier.  I am surprised though, that there is not more of an interest in syncing iterations. I’ve got to use a tool for execution, and ours is ADO.  So, if I am to synthetize, prioritize and plan in PB, but execute in another system, then it goes to follow that anything that simplifies the transitions between these individual systems is going to be helpful.  At least for me, the most common reason I need to push and pull data to an execution system like ADO is...  yea, it’s to plan and build our sprints.  What a joy it would be, to plan our releases, if our planning system could tell us whether or not our roadmaps are fantasies, based on the potential completion of the underlying work they represent.  So, I am missing something here, right?

Thanks.

Thanks, @Jaroslav_Tran.  Can you explain, how I should use PB in my handling of the following:

• I have feature X planned (in PB) to be available in a scheduled, upcoming release
• I received word from my Eng lead this morning, that there are issues that will prevent several of the remaining sub-features (ADO issues) required to release feature X. 
• He estimates they will get the remaining work done in the next iteration, but that’s 3 weeks away, and [insert dependencies here, ...], so I need to tell a number of customers, investors, executives that we will miss our commitment.

I, as a User of PB, want to be able to understand the impact a change in the engineering system’s issue status, has on the related planning data, so that I can update everyone and change the plan

Is that really not something you see demand for?  I find that hard to believe.

Now, if there is a way to get at the information that I need to have a view like this in pb, then we can stop here and ignore the rest of this email.  Otherwise, please read on.

Execution is not something PB is focused on in terms of functionality, and I hadn't expected any different, but I think respectfully, you need to get of your own way a bit here.  At a minimum, I think we can all agree that every team’s planning process is different as is every engineering team’s SDLC.  Clearly there is a need for this data by at least one of your users, and my guess is there are more that would benefit more generally, from the ability to bring data from their execution system into their planning system (and vice-versa, but for me to take up with DevOps). 

Whether it’s iterationPath in ADO as in my case, or any of the infinity of other data that are tracked in systems external to PB.  Why are you taking a position on which data I should be using or on whether or not I should have the option to do so? Might I suggest instead, that when it comes to integrating with the rest of the world, you and every other PM reading this, take less of position on what is integratable and get out of the way - or, said with a little more kindness, “give us the tools to get what we want”, so you dont have to waste time on this?  After all, wouldn’t having access to which data your Users are using in their interactions with other systems leave you better prepared as a PM to make decisions about what your Users need and dont need?  Kind of like putting the grass down and letting people wear their paths in before you decide where the sidewalks should be.

In this case, it seems like a graphql API would provide for all of these needs very nicely.  

Thank you.

Shawn