We need Features to span multiple releases.

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.

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

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.

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.

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. 

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. 

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

Great Idea.

Very helpful with rapid release or continuous development cycles.

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.