Skip to Main Content
Status Shipped
Categories Strategy
Created by Jonathon Leeke
Created on Apr 29, 2016

Initiative dates should be based on linked features, not releases

We have weekly releases, so adding Initiatives and Goals to releases is too much overhead.  As a result, I can't use the "Set Automatically" option for Start and End dates on Initiatives, since it's based on the individual linked releases for that Initiative. So, I don't have any usable timeline views for Initiatives, unless I manually adjust the dates, which is also not something I have time to manage.

But as a solution, I do consistently link Features to Initiatives (side note: we renamed Initiatives to "Epics" and use the Product Line Initiative as our "Initiative" level).  When building Epic/Initiative timelines, I want dates to be based on when the underlying *Features* are being developed (ie. their respective release time frames).  For long term planning, I'd rather drop a placeholder Feature in a future release than have to manipulate the Initiatives on every release and keep this updated over time, particularly since this value is not as visible to the user.  When release plans change it normally means I'm just moving features, not updating release details.  This is too much to maintain - Features are the center of our roadmap universe, and I'd rather timelines be driven by them.

Release time frame 1 month
  • Attach files
  • Ken Murphy
    Reply
    |
    Nov 13, 2019

    Even 3+ years later I strongly disagree with the Admin Response and fully agree with the user posts. Link features to an initiative, then derive the initiative timeline from the releases in which the features are scheduled. Fundamentally, initiatives are fulfilled by a collection of features - NOT releases. You've missed the whole point, Aha! and could take your automation to the next level, providing real value to roadmapping.

  • Puneet Singhal
    Reply
    |
    Aug 28, 2018

    I agree with both comments above.  This is getting unmanageable.  I do not understand the value that Aha adds with initiatives if we are unable to roll-up features status, or start date or % complete (based on story points calculation).  I wanted to remove this manual tracking in the first place.  Jira Portfolio does this beautifully.

  • Guest
    Reply
    |
    Aug 25, 2016

    This is also a key issue for my team. We have a large roadmap and set of initiatives. Initiatives are driven by delivery of key features and to be able to best represent initiative progress the Initiative roadmap is a key tool. Having to manually adjust the roadmap as we move features between releases means we need to maintain a manual mental connection. This is prone to error. This is a key feature to making the Initiative roadmap a powerful tool. 

  • Jonathon Leeke
    Reply
    |
    May 12, 2016

    This is unmanageable to have to keep release Initiatives up to date with the features in that release just to get a basic timeline view of how long an initiative will be in development.  I'm not sure what value the release Initiatives provide when you can link Initiatives to the underlying features - they should roll up to the release automatically to avoid duplicate data entry.

1 MERGED

Drive initiative dates by contained requirements rather than releases

Merged
I would like the Initiative start and end date be driven by the underlying master features and features rather than the releases that contains the MF/F. Today if a development team moves a MF/F from one release to another, we need to manually upd...
Kristian Haglund about 4 years ago in Schedules 0 Shipped