Just make a new story for your new requirement.

The question in your title may not have a generic answer, but let’s consider your example:

As a user I want to maintain a user profile

Suppose you had a definition of done for this story, including the ability to edit and save the home address, telephone number, and a few other things. The Product Owner agreed, the story was estimated and pulled into sprint. Later it was marked as done and the story points were earned.

If you change this story, this will induce a scope change of the original story. It also shows a drop in your burndown, even while you delivered high-quality work as was agreed upon before taking it up. See this related question. Make a new story, accept that it’s tiny, and pull it in when you need to fill up your sprint with something small.

Learn from this, and adjust your definition of done each iteration so that it includes a once-over before the end, to prevent trivial additions before it’s too late.

Once a story has been committed to in a sprint, that story should not be allowed to change any more.

Now, if the user comes up with a new idea halfway through the sprint that would affect one of the stories in that sprint, there are a few ways to handle that:

• Abort the sprint and start planning a new sprint. This has a huge impact and will usually be an option of last resort. It is mainly useful if the new ideas of the client completely invalidate the work currently being done.
• Remove the affected stories from the sprint. If a few stories are invalidated by these new ideas and are considered to have zero (or even negative) value, then you can decide, in collaboration with the client, to remove those stories from the current sprint. The resulting gap in work could be filled with work from the product backlog.
• Add the new ideas as stories. This should be the most common option. If the original stories still have value, complete them as scheduled and add the new ideas as additional stories to the product backlog.
• If the changes are very minor (would result in a story of <1 story point) and the story isn’t done yet, you could decide to take the changes along with the original story implementation. This choice should be rare.

In your example of the ‘create profile’ story, the additional story could be that the user wants to store a Facebook link along with the other information in the profile.

The question if the change is a Change Request (which is typically billed separately) or falls under the normal work depends on your contract with the client and is a matter for the account manager.

I’m no Scrum expert (by any means) but I’m going to [naively] say that this should be a new User Story.

• You’ve already met your acceptance criteria on this Story.
  Taking on this change might jeopardise that achievement. (There’s probably a trendy, new name for this but we used to call it “Scope Creep” and it was never a Good thing).

• Adding a new data field probably means changing the underlying data store.
  That may or may not be a “quick” job, again putting your points at risk.

• Make it a new Story and put it on the Backlog, just like everything else.
  Sure, it seems like a Good Idea (and really important) when it comes up but, when faced with the reality of everything else that needs doing, it may well become [relatively] less important.

• You say that this is:

  “a new requirement which wont have any change in the user story definition”

  Well, if it’s a Change but it’s not changing the definition of this Story, then how can it be done as part of this Story? Surely it has to be [part of] a Story whose definition it does change?

In terms of documentation and handling the change in a strict Scrum framework it should be handled as a new user story and not allowed into the existing iteration but…

Let’s be practical and not create unnecessary overhead…that’s not Agile. If the coding/testing complexity/effort is so minimal that it takes longer to create, prioritize, and manage the new story rather than modify and complete under the existing story, go the leaner route and just update the existing story.

Remember, once you bump an enhancement out, your developers may need to warm up to the code again before making the change. Sometimes its more efficient just to make the modification on the fly and track the change against the existing story.

If You can live with the done functionality then implement it, no need to cancel the sprint, just write a new US for the added functionality. If you implemented the wrong functionality and went back and changed the business logic to the requirement for that added functionality than that change is a change request to remove and replace what was implemented.

In your example adding functional data boxes that have a tie back to the database are all new user stories. Within your example an epic.

For others if, what you are replacing doesn’t, really need a replacement but just an enhancement to an added functionality, then those enhancements would all be new user stories.