Quick doubt about Sprint Closure

The Sprint will end once the timebox for it ends. The team need do nothing more that Sprint to develop the product, since the goal has been met and a Done increment created. They can nevertheless start new work if they wish.

If the increment is Done, it may be released before the Sprint ends, thereby avoiding depreciation and delay.

Why then would the commencement of any new work risk compromising the integrity of this finished increment, which has the potential to already be in service?

Good point Ian. But what would be the benefits, or not, to keep working on a sprint where the business goal was already achieved? Furthermore, maintaing the timebox just for formality? What would be the consequences to start a new sprint? 

Of course we are talking about an isolated event. This kind of problem would be adressed on the retrospective meeting to avoid occurring again. 

I didn't perceive any guidance on Scrum Guide about it. Is it something interpretive? I could assume that there is no right or wrong in this particular case?

Backlog items compromising the earlier increment? - It is quite surprising to read this.

If you already know that backlog item is going to impact currently being built increment, you should have stopped working on those stories. And re-refining such stories will make much sense.

what would be the benefits, or not, to keep working on a sprint where the business goal was already achieved? Furthermore, maintaing the timebox just for formality? What would be the consequences to start a new sprint? 

I'd suggest that a team may choose to start new work in order to optimize flow across the Sprint boundary: https://www.scrum.org/resources/blog/flow-optimization-sprint-boundary

The Sprint is a timebox. At the start, it has a fixed duration that is used to organize all of the events contained within the Sprint. Ending or closing a Sprint early has implications regarding the Sprint Review and Sprint Retrospective events, as well as the Sprint Planning for the next Sprint. Keep in mind that, in Scrum, nothing happens outside of the Sprint.

If the team has achieved the Sprint Goal and there is still time before the end of the timebox, there are several options.

One option would be to pull in more work. However, this is my least favorite option, especially if you can't get the work to Done and integrated into the Increment. You don't know what the Sprint Review's feedback will do to prioritize this work and starting work only not to finish it is wasteful. The choice becomes finishing work that is ordered lower to get it to Done or stop work in progress and waste the effort.

Another option would be to improve the quality of the product. Without knowing what your product is, it's hard to give concrete advice here. Still, there may be small things that you can do that would positively impact the quality of the product that can be implemented and incorporated into the Increment or a way to change your way of working by building tools that can make doing quality work easier in the future.

A third option is skill-building. One of the key aspects of the Development Team is cross-functionality. The remaining time can be used to increase the team's skills in an area that they are weaker in. This doesn't necessarily have to be technical skills. It could also be developing a better understanding of the product's domain or how it's used or product management techniques to allow the Development Team to assist with expressing and ordering Product Backlog Items.

It would be good to open the Sprint Retrospective discussion to understand why the forecast was off and what can be done to improve it. It may also be useful to have a regular approach to what happens when the goal is achieved before the end of the Sprint so the team knows what options are available to them and what the preferred option. This allows them to self-manage their time and organize around the goal and the team's way of working.

This is great guys! Thank you for your replies. It was helpful indeed! 

I have all the answers that I need. 

BTW, great piece there Ian. Thanks for sharing.

Have a nice weekend you all!

I'd like to add a 4th optoin to @Thomas Owens' list. 

Option 4:  The team can use the remaining days of the Sprint to Product Backlog refinement.  Scrum Guide says 

 Refinement usually consumes no more than 10% of the capacity of the Development Team. 

But notice it doesn't say it can not consume more.  Skill building and refinement are the two items I recommend most. 

The Sprint is Time Boxed. If there are multiple teams working on the same product then the increment needs to be made with integrated from all the teams before the end of the sprint.

So possible options,

[1] Backlog refinement

[2] Identify the technical debt and add it to project backlog

[3] Training and learning (Either related to Agile or related to project/product]/technology]

[4] Innovation and planning [Something similar to SAFe Innovation and Planning]

[5] May be identify a relevant item from product backlog and work [Split the item and take only what can be done during the remaining time duration with in that sprint]

[6] etc.

Thanks.