One Velocity Question

First of all I would say don't get bogged down in points and velocity.  They are an aid to assist the team to plan, nothing more.  They are not credit for doing the work or a way of 'paying' the team.

In this scenario, it looks like the team didn't have a good understanding of the story when they estimated. I would just leave the estimate as it is and learn from it. The most important thing is to identify why the team misunderstood the story and look at ways to refine the refinement process so the team go into the sprint with their eyes open in the future.  

It's 4. You don't change the estimate after the story is done just because the under estimated the complexity. That's normal and you will face such situations on the ground. Velocity normalizes estimation errors automatically. Use this input to inspect and adapt the estimates of the stories( if any in the PB) that are relatively sized based on this story.

It's 4. You don't change the estimate after the story is done just because the under estimated the complexity.

True, but the question does not state that the story has been done. It refers to some time "after the fact", presumably of "estimation". It is very poorly worded.

What we can assert is that if the team discover that they have underestimated work while it is in progress, then they ought to re-estimate it so that the forecast of work remaining is as accurate as possible. The correct answer might then be any of those supplied, depending upon when the work was started (was it in the same or an earlier Sprint?) and when re-estimation occurs.

if the development team feel the wrong estimation done by them an earlier sprint then we can go for re-estimation and I should keep this point in mind so that I can discuss the under-estimation problem with the team in Retrospective too.

The question is what you mean by "After the fact". Do you mean the sprint started and on day 4 of the sprint the team said "this really needs to be a 7" or do you mean that the sprint in completed and the story/item is done and now the team wants to change the size.

If it was done and the sprint is done, then it doesn't change. If it is in progress and you're still in the sprint, change it.

Is this a question on a practice exam? If so, where are you taking this exam?

I mean the sprint is going on and after 3-4 days team told me this that story points for this story should be 7.

According to me I should not change the Story point because it will show the scope change in the burndown chart as well and this is not the good way to do this if I will do this time like if I will increase the story point then team will not be serious about the estimation next time they will again do the under estimation. So it's better to keep it as it is and discuss this in the retro meeting so that team can improve it for the next sprint and give the right estimation.

As far as the team is concerned, it doesn't matter that much, as your Velocity is mainly a tool for initiating a discussion, and only really has value in aggregate (the Estimate of any individual product backlog item has very limited value.) If the team wants to use this as an opportunity to "calibrate" or take "credit" and it will make them feel better, let them, although...let's take a look at that "credit" thing...

A lot of Scrum teams measure success based on Velocity, often because that is the only metric they know for determining "Sprint Success." This is because many folks that do scrum don't consider things like cycle time, days since last release, quality etc, and most teams never mature to the point where they can actually measure value.

So for them, they might feel that the NEED to adjust the points to make sure they get the right "credit." While it's not a big deal by itself, you should do some hard thinking on how your team is using Velocity and whether or not you're using it as a pulse for picking out trends and opportunities for improvement vs a delivery measurement mechanism, which brings me to what I think is the more important question:

How is Velocity being used within your organization?

If it's being used in unhealthy ways that are outside of your team's control (i.e. upper management is cross-comparing teams or punishing teams when their velocity dips from sprint to sprint) change the estimate. You're better off protecting the team in this case and avoiding outsider meddling while you put yourself in a position to make a change at the organizational level.

A Final Thought

In general, I avoid locking the team into estimates, especially if it's raised before the item is Done, otherwise, from the team's perspective, it can feel like they're being "punished" for getting it wrong. Rather than a learning opportunity you could inadvertently teach them to pad their estimates in the future "just in case." I mean ultimately everything will pan out in aggregate, but it's not behavior you want to reinforce.

I go for four story points.

Usually after the Sprint Planning, I wouldn't recommend modifying the story points of each user story.

Unless the user story is not completed in this Sprint, it is then estimated when it is put back to the Product Backlog.

If the team often adjusts the story points of a user story in Sprint execution, it is mostly because they associate the story point with the hour.

Story points are only estimates of relative size and should not be associated with actual work hours or workloads.

According to me I should not change the Story point because it will show the scope change in the burndown chart as well ...

Would the team have an up-to-date forecast of the amount of work which they believe to remain?

The Scrum Guide says: “At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.”

A team could use burn-up charts if it allowed for cleaner presentation.

A team could use burn-up charts if it allowed for cleaner presentation.

+1

Curtis also discussed a way before, a chart for stories and a separate chart for the tasks.

https://www.scrum.org/forum/scrum-forum/17090/burn-down-charts

the sprint is going on and after 3-4 days team told me this that story points for this story should be 7.

In working with my teams, I try to stress this fundamental position:  Once the sprint starts, points mean nothing.   The team has their Sprint Goal and their sprint backlog.   They should only be focused on the sprint work, and be able to assess whether they are on track to meet their forecast or not.

Relative story estimation, team capacity, and team velocity are all tools to be used by both the PO and the Development Team to plan the upcoming sprint(s).   Velocity is a planning metric - nothing else.   

If your organization is trying to treat velocity metric in any other way (i.e. - an indicator of productivity or team health), this should be immediately raised as a potentially destructive practice.   The organization should instead be concerned with the value it is delivering to customers and stakeholders.   A team could have a high velocity, but generate little business value, while a lower-velocity team could be making their customers happy at the end of each sprint.

My strong suggestion is to avoid massaging story point values during a sprint.   If the team believes an item is larger than originally thought, they should assess whether their forecast needs to be adjusted because of it, or whether they still feel confident in meeting their sprint forecast / Sprint Goal.   

Under or over-estimation is always a good topic for retrospective discussion and Kaizen candidates.   As a practice, I usually revisit item estimates with my teams every few months or so to assess whether the team is being consistent with all of their "3" items, or "5" items, etc.