In corresponding with Aha! support, Scott Goldblatt wrote:
You are correct in your observations that all Aha! integrations with issue tracking systems such as Pivotal Tracker are designed so that Aha! comes first in the process. The philosophy is that PM's own the backlog and do all their initial grooming, prioritizing, and planning in Aha! When ready, they then send to Engineering and their tool of choice to manage the How - how those plans are best executed.
and it was suggested that I follow up with an idea. Here's what I wrote:
It's true that the Product Manager does a lot of initial work in Aha!. But there's an awful lot of give and take when the stories reach the engineering team. We move stories around, we change them, split them into multiple stories, etc. etc.
Much of that work happens in meetings, where PM and Engineering review the stories in Pivotal Tracker together.
It's unlikely that any PM is going to have the discipline to also have Aha! open. It's unrealistic that the PM would stop the flow of discussion, laboriously make those changes in Aha!, send to PivotalTracker, then make sure Tracker refreshes and reflects the changes, before resuming the discussion.
I do think it's realistic for the PM to (sometimes after the fact) annotate the changes made in Tracker with Aha! IDs. That way, Aha! would be updated per the results of the meeting. It doesn't have to be automatic, but the fact that stories _must_ be created in Aha! in order to be tracked by Aha! is a big drawback.
We have several meetings per week. Pivotal Tracker's designed to be very dynamic, precisely so that we can make changes in real-time as we discuss.
Importing data only solves this problem for things that have transpired in the past. Without "true" two-way integration, it'll be a lot harder to make use of the PT integration.
I'm trying to take advantage of Aha! while working with several years' worth of stories in Tracker, so I'm marking this Idea as, "I need it... Yesterday"
|Release time frame|