You already have two answers to your question, on opposite sides of a spectrum, and since you mentioned you are a new PM, I think some explanations are needed regarding them.
Both of the answers are correct, depending on what approach you use for building your features. One leans towards Agile, the other towards more traditional project management. It's basically the difference between Adaptive and Predictive approaches.
The predictive approach, or traditional project management, relies on building detailed plans upfront. You figure out what you want to build, gather requirements, detail those requirements, build a detailed plan of what you will build, organize all the work needed to accomplish the goals laid out by the plan, construct a schedule, stick to the schedule, build the thing, test it, release it, celebrate your accomplishment.
This works well for some types of projects, but not so well for others. When you use traditional project management, you end up with things like the Iron triangle which involves balancing project constraints while you try to stick to the plan you built at the beginning. For building a house, or a bridge, or a highway, this type of project management is appropriate because these types of projects were done before and you have a good idea about various activities that compose the projects (although these projects also go over budget, over time, or build less than needed). For things like software, traditional project management isn't well suited for most software products. And the reason is that the nature of software development is different than building highways or bridges.
Enter Agile, which was a response to building software using traditional project management techniques. Being frustrated with how things got built in software development, some bright minds got together and created the Agile Manifesto to lay out what they thought was a better approach to developing software. Agile is a set of values and principles, a different mindset for building software. Something that right in the face of traditional project management is "Responding to change over following a plan". This doesn't mean that there is no planning in Agile, on the contrary, it just says that big upfront planning combined with trying hard to stick with the plan isn't the correct approach.
And the reason is, as one answer mentions, that users don't know what they want, and they realize what they want when they see it. So you have to build things fast, put it in front of users, get feedback, gain insight, then decide what to build next, build it fast, put it in front of users, get feedback, etc. It's no longer about a plan that needs to be respected, and when people ask for changes or new features to say "well, that's not in the plan we agreed, let's agree on a change process, where we meet and discuss if it's worth straying from the plan". This is what the second answer mentions.
Agile welcomes change, while in traditional management change is considered bad and has the negative name of scope creep, and must be avoided. This is not to say that in Agile you just make any changes that get thrown at you, it's just that you don't consider them bad (they are to be expected - simply because that's the nature of software development). Instead of trying to lay out a rigid plan upfront, when you know least about what needs to be built, and sticking with it, you just incorporate change requests and demands for new features into your approach, and rely more on prioritization than heavy planning (you plan as needed, when needed, and change direction instead of trying to stick to a direction chosen from the start).
With that being said, going back to your question, it seems you are doing some sort of Agile (you mention Rally, user stories, weekly meetings, demo) so the answer to your question is that it's not a problem to add new stories to almost completed features, simply because features are never completed, only abandoned. Adding new stories to existing features or creating new features and attaching the stories there is now just a matter of how you would like to organize your process. For the features themselves the question is if the changes are needed or not, or if the changes need to be added now or can wait for some later release (i.e. the prioritization I mentioned above).
To me it seems that you are building features with an Agile mindset, but think about the feature descriptions in a more traditional manner, as stages that you already completed and you are moving on, and don't want to come back to. You need to reconcile these two things and then you will know where to add the new stories and how to record the changes.
