Do we have a due date when this will be implemented?
This would be a big boost to getting our people to accept Aha.
My suggestion would be to map a release in Aha! to a release in Rally
Release in AHA = Production release dateMilestone in Rally = Production release dateRelease in Rally = When the work is being done. No relation to production date.Mapping the Aha Release and Rally Milestone together allows the user to get a list of all the features/stories/etc being release to production on a given day. Seeing when the work is being done (using the Release field in Rally) does not give a good indication of when the code will be delivered into production.
It would benefit our group if a new field was created in Aha that mapped to the milestone release, not the release. Stories under one feature are released in multiple milestones within a defined release period, often releasing after each sprint.
How would teams that do continues delivery configure Rally/Aha?
I understand why people are asking for this but I think it's going to become less relevant for many programs going forward. As we shift to a continuous delivery model for SaaS products there will no longer be releases as such and thus no Milestone objects in Agile Central (Rally) to represent releases into production. Instead when a code change is checked in on the release branch (trunk) it will automatically flow through the CD pipeline and then to the production environment multiple times per day. We really need to get away from thinking in terms of "releases".
You should use one or more milestones for any given feature in AHA. Milestones should be managed within Rally and sync UP to AHA, and not the other way around. Rally is the source of truth.
Features should map to a PI (Rally Release Field) when the work will complete and not a production release date. Actual production releases can occur multiple times within a PI, or even outside the boundaries of a PI, however the Feature will be completed, demoed, and approved within the PI (Rally Release Field). A single feature may have user stories/defects that are delivered in multiple releases (Rally Milestones) within a PI and should have the User Story/Defect Milestone set to the release date, the parent feature(s) should have 1 or more milestones based upon the child story/defect production release plan.
We are getting 19 votes. Is there a threshold or number of votes needed to be come an enhancement then how soon will it be slighted for the roadmap?
This would really help adoption at UHG/Optum, since our internal Scaled Agile Framework (OSAM) uses the Milestone timebox in Rally for our production deployments...NOT the "Release" field.
CI ~ Releases ~ Delivery on CadenceCD ~ Milestones ~ Deliver on Demand
These are different metrics. You may have multiple releases of work going into production in the same milestone - and you can also have multiple milestones within the same release. Using the Milestones and Release fields allow us to accurately show when something is in planned (release) when when something is being deployed into production (milestone). We deploy work into production to support business roadmap and strategy - not just because the day / sprint / PI (timebox) has ended.
I'm glad the status changed to "Likely to implement". Any target dates you can share?
Any update? 7 months and no response?
One more thing to add - a milestone in CA Agile is a single date (12/12/2017). A Release in CA Agile is a date range (9/1/2017 - 12/31/2017). I admit that the names are not good, but that's how the fields work.So unless Release in Aha! can accept a date range I think the system will fail, or constantly overwrite, when you try and import it from one system to the other until there is some way to resolve this.
You won't be notified about changes to this idea.