Skip to Main Content
Status Shipped
Categories Features
Created by Brooke Huling
Created on Oct 5, 2015

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.

  • ADMIN RESPONSE
    Mar 29, 2017

    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
  • Janet Julian
    Reply
    |
    Sep 19, 2017

    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.

  • Max Cascone
    Reply
    |
    Dec 9, 2016

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

  • Scott Ling
    Reply
    |
    Jan 5, 2016

    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.

     

     

  • Guest
    Reply
    |
    Nov 13, 2015

    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.

  • Guest
    Reply
    |
    Nov 5, 2015

    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. 

     

  • Cameron O'Rourke
    Reply
    |
    Oct 29, 2015

    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. 

  • Guest
    Reply
    |
    Oct 27, 2015

    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

  • Guest
    Reply
    |
    Oct 14, 2015

    Great Idea.

  • Guest
    Reply
    |
    Oct 5, 2015

    Very helpful with rapid release or continuous development cycles.

  • Jonathon Leeke
    Reply
    |
    Oct 5, 2015

    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.

14 MERGED

Allow Features to span releases because I don't want to have to repeat a feature that will be worked on during the course of multiple releases.

Merged
Why is it useful, who would benefit from it, how should it work?
J. Mile over 9 years ago in Features 1 Shipped
12 MERGED

Add a feature to multiple releases

Merged
Because we develop for multiple platforms in one sprint (iOS, Android, Connected TV, Roko, Xbox, etc.) it would be extremely useful and improve productivity if I could add a feature to multiple releases instead of just one release.
Guest over 9 years ago in Releases 2 Shipped