When to raise an improvement on user story?

A Sprint Backlog is emergent, and evolves as the work required to meet the Sprint Goal becomes better understood. Isn't the situation you describe just an example of that happening?

Hello Ian,

Yes, that's right. But the point here is should we create a task for the user story or an enhancement user story needs to be separately created in the backlog and further estimated. 

I am explaining here with an example - 

We have a user story to generate a document which contains customer's details such as name (as a heading centrally aligned), address, phone, email and general information about product. As part of the acceptance criteria it was defined that what all details needed to show in the document and in format the document will be downloaded.

Once the above feature was developed, it was found during testing that the address details are being displayed with extra line break which is not consistent with other details in the doc. For e.g. if product description was coming in multiple lines then it's not being displayed with extra line break. Also, Customer's name as a heading is much bigger in size.

When it was said to the development team that it would be good if we fix the above points, then they asked to create an enhancement story.

Is this the right approach here? Because what I understand about an improvement story is that it is created on developed feature or can be found as part of sprint review meeting.

I might be wrong, please correct me.

Yes, that's right. But the point here is should we create a task for the user story or an enhancement user story needs to be separately created in the backlog and further estimated

I'd suggest that perhaps this isn't the point. Scrum doesn't say anything about having tasks or user stories at all.

There is a forecast of work in the Sprint Backlog which emerges as more is learned about the team's Sprint Goal commitment. That forecast may be revised however the team see fit, and they can restructure the Sprint Backlog in whatever manner they think appropriate so the Goal will be better met.

The best time to bring up an issue or concern is as soon as someone realizes it. Then, based on what the issue is, the team can choose the best course of action.

Consider the example - someone is testing a change and finds a UI issue. As soon as they see the issue (and perhaps confirm it and how to reproduce it), it should be brought up to the team. There are then many options. Can the team correct this issue and still achieve the work necessary to meet the Sprint Goal? Does this issue prevent the Increment from being releasable? Who is impacted and what is the level of impact? Based on answers to questions like this, the team can make a decision on if the work should be done immediately, if it can be put onto the Sprint Backlog for later in the Sprint, if it should go into the Product Backlog to be ordered among all of the other potential changes, or if the issue really isn't an issue and nothing is required.

As far as "improvement stories", Scrum only has Product Backlog Items. It's conceivable that most teams also have work in their Sprint Backlog, but how that work is broken down isn't mentioned. Product Backlog Items include defects that need to be fixed, changes to existing features, new features or capabilities, and more - anything that represents work necessary to improve the product. If and how you categorize Product Backlog Items is up to the team. Who is responsible or allowed to create and insert Product Backlog Items is also up to the team, but managing the Product Backlog is part of the Product Owner's responsibilities.

As pointed out by the others, your issue really has nothing to do with Scrum.  It is about the way your team wants to process information and plan work.  Scrum provides guidance on how to accumulate information in a way that can help a team be more transparent and develop clarity on the work that needs to be done.  The information is accumulated in Product Backlog Items, not Product Backlog Stories. It also provides two mechanisms for organizing that information, the Product Backlog and the Sprint Backlog.  

Your issue stems from how to write stories, which is a mechanism that your organization has adopted.  Personally I have never heard of "enhancement stories" or "improvement stories".  But it apparent that your organization has gone to the effort to create classes of stories.  So the answer to your question is held by the people in your organization. 

Having said all of that there is one part of this that Scrum can help with.  The basic premise of agility lies in the empirical model and self-organized teams.  In this case your developers have asked for a process.  Why not follow the process, then use the Sprint Retrospective to discuss and analyze the situation.  This can become a topic for multiple Retrospectives as the situation arises. 

I also question these statements in regards to Scrum.

Once the above feature was developed, it was found during testing

When it was said to the development team that it would be good if we fix the above points, then they asked to create an enhancement story.

Does this mean that the people that develop the work are separate from the ones testing the work?  It sounds like multiple teams of individuals instead of a single team of developers.  Also, had the item in the Sprint Backlog satisfied the Definition of Done?  All of these are things that should be discussed in Retrospectives.  Scrum identifies a single role for the people doing the work to build valuable increments. That role is identified as Developers and those individuals are accountable for all the work done to create valuable increments. I would assume that testing is part of that work. The Scrum Guide provides this explanation of the Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The basis of your situation seems to be a lack of a Definition of Done that everyone understands and agrees to uphold. If I were you, I'd focus more on the Definition of Done as way to address your dilemma and less on the types of stories that are being created.