Is it allowed to change the Story Points after sprint initiated.

Think of it the other way around. Who would benefit from maintaining a false estimate? We would no longer have a true picture of the amount of work that is believed to remain.

What would investing time in changing the estimate offer to anyone?

If the team has chosen to estimate, once the Sprint has been planned - a Sprint Goal crafted, Product Backlog Items selected, and a plan created to achieve the Sprint Goal - estimates no longer serve any useful value. If the team has chosen to estimate, they should be aware of the fact that some work will take longer than the estimated time, just like they should be aware that some work will take less than the estimated time and some work will emerge during the Sprint.

The question to ask is if this additional, newly discovered complexity puts the Sprint Goal in danger. If it does, then the Developers may want to work with the Product Owner on what the best options are to maximize value delivered over the course of the Sprint.

Honestly, I have seen very few instances where the original estimate held up after work began.  That is to be expected because the estimate was made based upon information available at the time the estimate was created. When work begins, you will invariably acquire new information. 

The real question is what benefit is provided by updating the estimate?  Since work has begun that estimate is no longer useful.  At the point where work begins, all focus should be shifted to the ability to satisfy the Sprint Goal and the value that is delivered in the increment.  The "points" have no meaning. 

Interesting question.  Certainly there are teams that do change story points, either during a Sprint or when a story rolls to the next one.  When a story is put into the Sprint it should meet DOR, which includes pointing.  My view is to leave the point as it is and the team future estimates just need to be more accurate.  If a story rolls, just keep in mind (off Jira) that the work left on a story that was 8 may  now be a 2 so that you still add stories to meet team capacity.  Now, in some environments points and velocity are unfortunately used as performance measures.  I have seen this cause some teams to manipulate points, and repoint, so as to not garner negative attention.  I believe companies should not use velocity as a stick.  That said I had a team that did all the work planned in a Sprint and the Release team created a new requirement for all stories the last day of the sprint with would have resulted in 3 points of 25 delivered.  In this case we split the stories that we thought were completed, removed the new requirement out of each story with 1 point each and repointed the stories with the 1 point removed and completed them.  I am not suggesting this as a good approach, but having a sprint with almost no stories meeting DOD would have unfairly represented the team's effort and skewed metrics going forward.  So this is one example when we as a team bent the rules.  It seemed the lesser of two evils.

User story can be enriched, updated or even new User story added when Sprint is started as new information becomes available.

If this increases Story Points, thern it would even be correct to change the Story points to porvide Transeperency, so that it also presents right information and gives the team the hint for further sprints.

P.S: Keep in mind that you keep the entire team aware of this (do not forget about PO), and if your investigation put your commitment under a risk, you collaborate together and find the right solution.

Some work might be more difficult than anticipated, some may be easier. With complex work we don’t know until we get into the work.

Others have called this out, but what is the value in updating the estimate?

Outside of the estimate, it is good to bring transparency to the fact the work is harder than anticipated. The team can inspect that and determine if adaptations are needed, be it to the scope of the work or perhaps removing other non-Sprint Goal items so the team can focus on this item and still achieve the Sprint Goal. None of these activities require an update to the estimate.

To your question of “Is it allowed to change the Story Point in this case?”. Story Points are a complimentary practice. Not part of Scrum. The topic of sizing is only mentioned 2x in the Scrum Guide…

This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing.

There are some great questions and suggestions offered by Ian, Thomas and Daniel to consider.  

I am an advocate for always doing this with my teams. 

It increases the transparancy of the work that is currently being worked on, and more importantly creates a situation where the team can inspect and adept their plan for the sprint. Especially if it means the sprint goal might come under risk. 

This also helps the product owner also notify stakeholders earlier during the sprint to manage their expectations. 

Story points are forecasts made by developers for their own use, to control their own progress.

In a nutshell-based on their own hanches.

Scrum team can use any technique they want to monitor and forecast progress. Most important thing is to use empiricism and feedback loops, the rest is Developers own business.

Which means they can not only "change story points", if the work turns out more or less complex, but wipe the story points out altogether, and use different techniques if the Scrum team considers this step necessary.

Just make sure that story points are kept as far from management and stakeholders as possible, and protect developers from the external attempts to "weaponize story points". "Weaponisation" means using story points as a metrics for teams performance, or worse, for payroll.

Hi,

In Agile development, it's okay to change story points if the team realizes that a task is more complex than initially thought. If a developer estimates a story at 3 points but discovers extra challenges during implementation, they can adjust the points. Agile encourages adapting to change and learning from experience. It's important to communicate with the team about the reasons for the adjustment.

https://www.scrum.org/forum/scrum-forum/76595/it-allowed-change-story-points-after-sprint-initiated

I hope this will help you. 

Hello,

In Scrum, which is an Agile framework for software development, it is generally recommended not to change Story Points once a sprint has started. The Story Points assigned to user stories are intended to reflect the team's collective understanding of the effort required to complete the work. Changing Story Points during a sprint can disrupt the stability of the sprint and affect the team's ability to plan and deliver.

However, Scrum is also about inspecting and adapting, so if there is a valid reason to change Story Points during a sprint, the Scrum Team should discuss it during the Sprint Review. The Sprint Review is an opportunity to review and adapt the product backlog, including the estimates. The Product Owner and the Development Team can collaborate to adjust Story Points based on new insights, changes in requirements, or a better understanding of the work.

It's important to note that changes during a sprint should be minimized to maintain a stable and predictable development environment. The team should aim to have a clear understanding of the work during Sprint Planning to avoid unnecessary disruptions. If there is a need for frequent changes to estimates, it may indicate a need for improved collaboration and communication within the Scrum Team.

In summary, while it's generally discouraged to change Story Points after a sprint has started, if there are valid reasons for adjustments, the Scrum Team can discuss and make changes during the Sprint Review as part of the inspect-and-adapt process.

If the Story points are very different it is possible that the delivered product increment has some very real differences, perhaps not to the end user, but in testing magnitude that impact the QA/Test Automation teams, User testing effort, or in scope that impacts the implementation process and documenters. Dependencies may also need to be accounted for that may pull it out of the current release. It is possible in most software for a PO to clone the existing story, re-estimate it with the additional subtasks and close the original as a duplicate - linked to the new story, with notes, and removed from the release. This would retain relevant history.  

I suggest to think about the purpose of using the Story Points. It is a complementary practice to Scrum that supports teams with forecasting.
If in the current Sprint new or more work is identified to reach the Sprint Goal, then the forecast needs to be updated, so that it reflects the actual remaining work. In this situation it feels important to update the Story Points.
When forecasting future Sprints using Story Points, it is important to have a reference base of past work. Given the team understands the past work, they can compare new work against it. The baseline (i.e. the past work) needs to show the actual experience and insights of the team. In this situation again, it is important that Story Points are changed to the latest understanding of the team. So again, please have up-to-date Story Points.

A lot of teams do not dare to change their forecast, as it shows that the Sprint Goal might not be reached. So be it. The team can learn from this.

This is one of the aspects that brings transparency.

Remember though: Story Points is a complementary practice. If it works for your team, great! If it doesn't, use another forecasting practice.

You might be interested in my blog posts about the fundamentals of the Scrum framework. If so, please check out this page: https://boostyourscrum.com/professional-scrum-foundations-series/

Hope this helps.
Feel free to shoot more questions!