We need Features to span multiple releases.

We build features across several releases or we break them into smaller marketable components of the larger feature.  We really need a way to tag a feature to multiple release vehicles.

  • Brooke Huling
  • Oct 5 2015
  • Shipped
Release time frame
  • Mar 29, 2017

    Admin Response

    Today, we have introduced Master features -- a powerful new capability for your bigger work items. Master features can be used to group features together which span across multiple releases. You can use Master features are another level in between your existing strategic initiatives and features.

    Read more about it here: https://blog.aha.io/epic-roadmap/ 

  • Attach files
  • Jonathon Leeke commented
    October 5, 2015 17:44

    Yes, since features are not necessarily confined to a sprint, that means they may also split releases.  It's hard to show how we work on a feature in multiple releases.  For now, we usually do a Phase 1 (ie. "MVP") and then Phase 2 ("iterate") feature, but it's sometimes hard for our stakeholders to understand the distinction.  Or if we ship some parts "dark", there may be nothing to communicate, but we still need to track that we're working on that feature in multiple releases.

  • Reed Smith commented
    October 5, 2015 18:44

    Very helpful with rapid release or continuous development cycles.

  • T commented
    October 14, 2015 17:22

    Great Idea.

  • Ed Henderson commented
    October 27, 2015 16:45

    I just saw this, and wanted to put my $0.02 in.. FWIW.

    Frankly, I think this is a bad idea. I'm sorry, but if you know anything about *agile*, then you know that features/stories are specifically designed as items that can be completed in a sprint. They don't span a sprint, let along a release.

    The way you span things across sprints/releases would be to have an Epic/Initiative, then create a list of finer grained items that you can release in pieces.

    There are plenty of important things Aha! needs to work on, this, IMHO, is not one of them.. this should not even be on the list, let along near the top. How the heck does this have 25 points?

    Why can't I downvote this??? Grrrr

  • Cameron O'Rourke commented
    October 29, 2015 18:01

    I agree with Ed. Initiatives span releases and sprints, Features may span sprints, Requirements (sub-tasks) in our environment do not span sprints. 

    Having said that, I don't know if the default Aha to JIRA mapping is really the best way to set up Aha and JIRA, I suspect that there is a better default mapping that lets PMs plan at a sufficiently high level, and engineering teams work at a sprint level. 

    I would love to hear from others on what is working for them. 

  • T commented
    November 5, 2015 19:10

    I think maybe this could be achieved through adding a relationship between a feature, perhaps a better option would be to have the ability to display relationships between "phases" on the roadmap/feature page if you wanted to make them relate. 

    Note: I know currently we can only view these relationships when we open the feature itself. 

     

  • Patrick Strick commented
    November 13, 2015 14:35

    I agree with the idea. But, I agree because as Cameron said the default mapping (to Jira at least) of feature = user story doesn't make sense in our company. Our stories are fairly granular and in themselves do not represent a complete "feature" that I would use for planning, much less share with stakeholders. Our idea is having initiatives not mapped to anything and features mapped to epics. However, epics can and do span sprints and sometimes releases.

  • Scott Ling commented
    January 5, 2016 09:26

    Ed's comment was great. I would like to ad to it as an Agile practitioner/trainer (past life :) )

    TLDR; read last paragraph for a solution, Top section for why in Agile you should not have a story/feature span a release.

     

    Normally, in a sprint if a story is not completed it is treated as failed, and not delivered - for time keeping/costing you record time else where.

    But for product implementation work, its either done or not done.  if it cant be completed in a sprint and you know this upfront, you should split it - but each story should be demonstrable as complete.

     

    If not done its simple not released, work is reviewed in planning, feature is now moved into next sprint or release. and done.  Other wise you are breaking the promise you are making on delivering items in a sprint.

     

    Finally, if its a big feature that spans many releases - you could just turn it into an initiative and assign broken down features to it - this way an initiative can be across multiple releases - and will not break agile process or promises on delivery.    We do this for a rolling UX/UI initiative right now across our product range for example as we know its a good 3-6 month job.

     

     

  • Max Cascone commented
    December 9, 2016 19:55

    I agree with Ed and Scott. If a Feature needs to be made "bigger", turn it into an Initiative ( == Epic). 

  • Janet Julian commented
    September 19, 2017 19:08

    Master features are great, but rather than placing them in releases individually, I'd rather see them linked to the releases that their component features are in so that I can see where my Master Feature is getting worked on when I look at it.