Rally Software

When scheduling a Release it is pragmatic to assign the Backlog of User Stories a provisional Iteration to help develop a top-level schedule.  This doesn't break Agile, just allows sanity checking for Releases which have to complete by a given date.

Feature Start and End dates have to be set as dates and this requires manual intervention to create and maintain. it would be a significant advantage to be able to set the Start and End Dates of a Feature according to the Iterations of the User Stories assigned to it, both actual and provisional.

Peter, in your use case I'd just use the Release Tracking page to see in which iterations a Feature is being worked and delivered. I understand the value of entering the dates for the feature based on story scheduling so that you can use things like the Portfolio Timeline, but it shouldn't require any fancy querying to answer the question. Am I missing something? Hope this helps.

Yeah, the Tracking view works, but it's tedious to transfer this to individual Features. Setting Feature dates based on the sprint layout of the API is really helpful. It's definitely possible to do with a script, but it hasn't been *quite* painful enough for us to do that yet.

HI Eric, Rick - thanks for getting back to me.

The rationale behind the ask is that whilst we all embrace the Agile approach for the advantages it provides, in my world we are always aiming to hit a date that has to align with something beyond my ability to influence e.g. the HP Discover trade event or some release date that is constrained by the requirements of our Sales or Logistics organisations.

So we have to perform high-level planning up to a year ahead to be ~ 80% confident that the scope we are promising can be delivered because is difficult to change manage it once our Sales and Marketing  \ Logistics juggernauts start to roll - and Agile they are not.

So I'm looking for a compromise solution where we perform essentially waterfall long-term planning by means of  the Start and End Dates in a  hierarchy of Portfolio Items, then Sprint-based Agile Development by means of User Stories assigned when needed from a Backlog.  The planning element would be much easier if a Theme's  Start and End dates were set by the dates of the Initiatives assigned to it and an Initiative's dates were set by the Features within it. That would allow Feature level planning to ripple up the hierarchy, removing the need to do this manually.

At the Feature level a similar advantage would be gained if the Feature dates could be updated according to the Sprint allocation of the Use Stories assigned to it. For most of the time it would not matter but it would, crucially, allow the impact of an overrun of the Backlog work assumed for a Feature to be considered before having to reduce the scope to fit.

Hope that helps explain

  Pete