How to do release management in sprint?

My understanding is we can do multiple releases within a sprint as each completed PBI during sprint is an increment. By release, I mean moving user stories with DOD to production for end users. However, my questions is how sprint review should be conducted for such increments within sprint?

The purpose of the Sprint Review is to "inspect the outcome of the Sprint and determine future adaptations". One outcome of the Sprint worth inspecting is the cumulative sum of the releases. However, you can also look at if and when the team met the Sprint Goal. However, I'd recommend using the time in the Sprint Review to focus on the Product Goal and the state of the Product Backlog and how to best adapt the Product Backlog to meet the needs and expectations of stakeholders. Don't focus too much on the outputs, which can be a trap that a team can fall into if they use the Sprint Review as more of a demo period.

Another question on release planning.One of my team have predefined release cycle of 1.5 months. In this time frame we can almost finish 3 sprints? Can we combine 3 sprints together and do release in production. Is this correct?

There's no need to release at the end of every Sprint. There are multiple ways to handle this, depending on how often you are ensuring that your Increment is in a releasable or shippable state. The end result would likely be deploying the last Increment, which could have been produced in the current Sprint or the previous Sprint.

Should we estimate defects reported in production? If yes, should we count story points of those defects in next sprint velocity ? Please guide on how effort and estimation should be done for production defects?

This is entirely up to the team. If the team has opted to estimate, then I'd suggest that the team estimate all planned work. That would include an issue that escaped the development process into production and needs to be ordered among all of the other work being done by the team. Following that, you should use that estimate the same as any other estimate. If you use estimates to determine how much work to plan for the upcoming Sprint, then you should do the same.

How high priority and extremely urgent show stopper production issues should be tackled in scrum? If development team agrees that it can fix issue in current sprint, should we remove stories from sprint backlog and replace it with bug estimates? Let's assume this doesn't happen often or frequently.

The Developers are in control of the Sprint Backlog, so they ultimately decide what to do. I would tend to advise leaving the planned work in the Sprint Backlog and add the new work to it. Understanding the state of the backlog at the start of the Sprint and what was added can be useful for discussion at the Sprint Review and Sprint Retrospective. The most important thing isn't how the team tracks the work, but how they address issues in product and process quality to ensure these "high priority and extremely urgent show stopper production issues" do not escape the development process in the future, either through the Sprint Retrospective or through some other root cause analysis methods.

Thanks Thomas for detailed reply. I have a query on this "I would tend to advise leaving the planned work in the Sprint Backlog and add the new work to it" . If we are adding new stories(bugs) in sprint after starting a sprint and not moving existing items of equivalent estimates out of sprint than anyways we have to do same at the time of closing sprint i.e. at the end of sprint.Though there is a possibility that team can achieve more than planned capacity for the sprint.

my questions is how sprint review should be conducted for such increments within sprint?

The key output of a Sprint Review is an updated Product Backlog and it can be seen as a workshop for that purpose. How do you think that workshop will be affected?

One of my team have predefined release cycle of 1.5 months. In this time frame we can almost finish 3 sprints? Can we combine 3 sprints together and do release in production. Is this correct?

Why would covering up this loss of empiricism due to an attenuated release cycle be correct?

Please guide on how effort and estimation should be done for production defects?

How high priority and extremely urgent show stopper production issues should be tackled in scrum?

Improve the Definition of Done so increments become of usable quality. Developers may then use that Definition to re-estimate the amount of work that is truly believed to remain on the Product Backlog, including any technical debt.

If development team agrees that it can fix issue in current sprint, should we remove stories from sprint backlog and replace it with bug estimates? Let's assume this doesn't happen often or frequently.

Is enough contingency being planned into the Sprint Backlog to manage this risk occasionally presented to the Sprint Goal?