Subtask Estmiation

The only purpose of estimation is so a team can get its arms around how much work it can take on in a Sprint, so a Sprint Goal will then be met. All else reduces to matters of value and empirical process control.

Is your team delivering valuable work of immediate release quality every Sprint, and are they achieving their Sprint Goals?

Is there any issues in the way that we are following if so please update

Scrum doesn't forbid estimating sub-tasks or require it. Do the Developers doing the work find the sub-task estimates helpful? What problems has this solved for them? If there isn't any value added for the Developers, might it just be a waste of time? Perhaps time could be spent focusing on the Sprint Goal rather than sub-task estimation if there isn't any value.

Estimation for the story ie.subtask estimation is done before sprint is calculated. If in case a new subtask is created and estimated after sprint is started will it affect the sprint scope by any ways please update.

As mentioned by Ian, the focus should be on the Sprint Goal and achieving at least one valuable Increment by the end of the Sprint. Excpect that the Sprint Backlog should emerge and change throughout the Sprint, as more is learned. In complexity plans are never perfect. Thinking that your plan will be perfect upfront isn't realistic and is why empiricicsm is so important. It's Scrum's DNA. Help your Scrum Team embrace uncertainity and to respond to changes.

[1] it is better to create the sub task before the sprint start

[2] If that is not possible if the user story was estimated correctly and all the sub-task stories sum is equal or less then user story story points initially identified during user story backlog refinement/gromming or sprint planning, then it will not impact the burn down chart in the end of the sprint.

@Vijay

[2] If that is not possible if the user story was estimated correctly and all the sub-task stories sum is equal or less then user story story points initially identified during user story backlog refinement/gromming or sprint planning, then it will not impact the burn down chart in the end of the sprint.

I only do story point for main story and not for subtask. Subtask is for easier split up of the task that developers are going to do and it helps them to come out how much time is required for story completion. So it helps me to judge how much is the developer occupied for a given sprint.

@Chris Belknap - By providing subtask the dev. can understand what they are going to do and how much time is going to take for story completion.

@Ian

Is your team delivering valuable work of immediate release quality every Sprint, and are they achieving their Sprint Goals?  Not 100%  but 90% they are delivering valuable work

I only do story point for main story ...

So it helps me to judge how much is the developer occupied for a given sprint.

Those two statements sound like something a Project Manager would say.  Unless you are a developer you shouldn't be participating in the story pointing and even then you will be only one person involved.  Why do you need to "judge" developer occupancy in a sprint?  In Scrum, all Developers are fully occupied by Sprint activities since the entire team is responsible for the work. 

Subtasks are useful for some people but not for all.  And if you are being successful in your Daily Scrum, everyone should know what the others are doing.  That is the purpose of the event.  Too often I see teams try to use subtasks as a way to circumvent the discussion and planning that the Daily Scrum is created to provide. As for estimating time and then updating that time, is it really useful?  How often have you gone back to look at the data collected for those subtasks as a means of improving?  If the answer is zero, then you are wasting your time updating the information.  And if you say "we do it all the time" I would ask what you are getting out of it?  Because every time you do an activity you learn something that will improve your ability to do it again.  So the actual time you spent last time will most likely change for each subsequent occasion that you repeat the same work. 

Software development practices evolved to make teams have more agility by looking at practices used in manufacturing.  Lean manufacturing practices were adapted to software development activities to reduce the wasted efforts undertaken by software development organizations.  If your subtasks and the methods you use for them are not providing benefit or are creating work, you should really question whether they are worth continuing.   Your original question and your response does not indicate whether the team feels that that there are issues with your practice.  And ultimately the Scrum Team are the only ones that can provide such an answer.  So ask them how they feel about their current practices, whether they feel there need to be changes, and what are those changes.