Skip to Main Content
Status Future consideration
Categories Releases
Created by Guest
Created on Mar 21, 2019

Add concept of sprints/iterations as child of releases

As a Product Manager, I am more concerned about when features will be launched & made available to end-users. The developers and engineers I work with are more concerned about what work they will need to complete in specific sprints or development iterations. 

Our conflict arises from the fact that Releases used as sprints/iterations starts to get horizontally cluttered. Having one Release, however, causes issues for the developers in understanding/reflecting the sequence in which their features/tasks need to be completed; in addition to not having a good way to reflect iteration-level estimates. 

If it were possible to organize features in a release into sprints or iterations, that had their own notion of estimates/pointing/burn downs, it would go a long way in easing some concerns that arise between Product Management & Engineering/Development. 

  • Attach files
  • Admin
    Kelly Sebes
    Reply
    |
    Nov 26, 2019

    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.

  • Guest
    Reply
    |
    Oct 11, 2019

    @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!

  • Stephanie Redl
    Reply
    |
    Jul 3, 2019

    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.

  • Mark Taylor
    Reply
    |
    Mar 29, 2019

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