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.
You won't be notified about changes to this idea.