Add concept of sprints/iterations as child of releases

Hi Stephanie,

Good news - the situations you describe in Scenarios 3 and 5 now behave as you would expect. You can read more about the recent sprint improvements to the TFS / VSTS / Azure DevOps integration on our blog here.

@Mark Taylor - When would you recommend we push Stories to JIRA? As a large group? Where do they land in JIRA (what queue) so that users can then plan Sprints in JIRA?

Thank you!

Adding sprints as children of iterations would maybe help also with issues of the integration with TFS/Azure DevOps. The integration allows only the mapping of Aha! releases to TFS/ADO iterations (we tried with a separate release work item in TFS but that causes other issues). Iterations are typically releases with sprints as children, in a hierarchical relationship. Now the iteration itself gets referenced as a path in the user story, e.g. [Product]/[Release]/[Sprint]. The integration setup currently does not allow choosing the level of the path that would need to be mapped to a release record in Aha! which results in sprints being created as releases in Aha! - but only in some cases. 

Example:

• TFS Project [ABC]
• Aha! Product [abc]
• Release [abc 19.10] in Aha = TFS iteration [ABC 19.10]
• TFS iteration has two children [ABC 19.10 Sprint 1] and [ABC 19.10 Sprint 2]

Scenario 1: Create user story and release assignment in Aha and send over to TFS

• TFS user story gets assigned to the correct iteration [ABC]/[ABC 19.10]

Scenario 2: Create user story and iteration assignment in TFS and send over to Aha

• Aha feature gets assigned to correct release [abc 19.10]

Scenario 3: Create user story in TFS, assigned to the first sprint and send over to Aha

• New release gets created in Aha [ABC 19.10 Sprint 1], feature gets assigned to that release
• PM needs to manually move it to the correct release and delete the sprint-release

Scenario 4: Create user story and release assignment in Aha, send to TFS, then change sprint in TFS

• TFS user story gets assigned to the correct iteration [ABC]/[ABC 19.10] on initial import
• the Aha feature keeps the release, sprint does not get created as release

Scenario 5: Move TFS user story from one sprint to the sprint of another release

• the Aha feature keeps the original release, it does not get assigned to the new release (also no new sprint-release gets created)!

So, in Scenario 3 and 5, manual work is needed to reflect the changes in release or sprint assignments done by the R&D team.

I'd suggest you use the Jira integration for this. Aha! is a Roadmapping and Portfolio Management Tool, not a Work Management tool.