What is harm in combining sprint review and retro?

What would this mean for the team's focus on these two separate concerns, and on their ability to inspect and adapt accordingly?

What, exactly, do you mean by "combine"?

Logically, the Sprint Review and the Sprint Retrospective are two separate events. They have different purposes, different participants, and different expected outcomes. Therefore, it makes sense to discuss them as two separate events when discussing the Scrum framework.

However, nothing in the Scrum Guide prohibits holding a Sprint Retrospective immediately following the Sprint Review. To the people participating in both events, this would seem like a combined event. Just because you can structure your events this way doesn't mean it's a good idea. Not only would holding both events back-to-back result in a long, grueling session for members of the Scrum Team, it would not give the team the opportunity to review and potentially refine feedback received from the Sprint Review.

Thanks Thomas, Thanks for sharing your detailed views here.

Now, this was case where we had less participation in retrospective, so the thought process was that we conduct this two events together, first sprint review and followed by sprint retrospective, given stakeholders had the option to drop off when we kick off sprint retrospective.

So combining is the second to last event with the last event if it is feasible, and everyone sees value in it.

Basically, one way it could be long, but in a certain scenario it can be valuable to have it in one go.

Below are only refernces from scrum.org itself.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter

Thanks Ian for the feedback, but are we certain that if we have these two events together and everyone sees value in it, to have one event , it is not beneficial?

given stakeholders had the option to drop off when we kick off sprint retrospective.

What if stakeholders do not drop off and hang around during the retrospective? Will the team be comfortable discussing on issues like technical debt when stakeholders are around?

You mentioned that there was low participation during the retrospective, did you check with the team on why they do not see a value in the retrospective? The reason why the two events are different is because they serve separate purposes (review- Inspect and adapt the increment with stakeholders and identify next steps towards the product goal, retro - inspect and adapt processes, team interactions and together discuss on how to improve quality and efficiency). By combining the events it seems you are trying to enforce people to attend retro as well along with review (which they seem to attend otherwise).

I would suggest to use retro as an opportunity for the teams to unwind (set up an atmosphere where they can relax a bit with coffee may be). Conduct it in a way that people are interested and look forward to it rather than avoid it or feel forced to do it.

Beneficial is not the same as effective. It might be beneficial for me to combine my upcoming root canal and massage to save me some time and make it more convenient, but I imagine it won’t be very effective for those involved. 

You reference low participation during retrospective as a reason for combining these two events. If retro participation is low now, just imagine how low it might be when you add Stakeholders into the mix. 

Consider this line from the guide: “Failure to operate any events as prescribed results in lost opportunities to inspect and adapt”. Each Event is intended to be eventful, each with it’s own purpose and participants. How might combining Events and changing participants impact that? 

If the problem lies with the retrospective, I would focus on what I could do to improve retrospectives to improve participation and effectiveness of that event. 

Now, this was case where we had less participation in retrospective, so the thought process was that we conduct this two events together, first sprint review and followed by sprint retrospective, given stakeholders had the option to drop off when we kick off sprint retrospective.

Personally, I wouldn't consider this to be "combining" the events. You still have two events with two different groups of participants, but they are scheduled back-to-back.

I still see a few risks:

1. You're delaying considering the feedback from the Sprint Review. Based on what happens at the Sprint Review, the Product Backlog could change. It could be a significant change, like a new Product Goal. It could be a minor change, like shuffling a few Product Backlog Items or adding/removing a few Product Backlog Items. Depending on the changes, it could be useful to do some refinement to make sure the Product Backlog is ready for Sprint Planning. If you slide immediately into a Sprint Retrospective, you have to wait until after that concludes before taking this action.
2. Long meetings are terrible for focus. A Sprint Review could easily be 4 hours for a 1-month Sprint. Without proper engagement, people could lose focus after a little as 15-20 minutes. Giving people a decent break between the Sprint Review and the Sprint Retrospective can make sure the Scrum Team is engaged and actively participating in both events.

@Ryan took my thunder. I was going to use the same example of combining two events.  But I like his choice of events better than the ones I was going to use. 

If your concern is lack of participation in the Retrospective, then ask everyone to attend a special retrospective to discuss why they feel that event is not effective.  That fits the purpose of the retrospective as it allows the team to adapt their behavior to better perform as a cohesive team. Find a way to make it less of a gathering and more of a purpose. Sometimes, it can help to just change up the format of the event.  

From the teams I have worked with, the main reason that they do not like attending the retrospective is because it is a "negative meeting".  First, it isn't a meeting. It is an event.  Just like a festival is an event. The birth of a child is an event.  The celebration of an anniversary is an event.  Second, it isn't negative because it is focusing on how to become better as a team. Yes, you may talk about things that didn't work well but you should also spend time talking about the things that did go well.  You want to find ways to ensure that those successes continue. Find out why they do not like attending the Retrospective and help them to understand why it is so beneficial. 

Now, this was case where we had less participation in retrospective, so the thought process was that we conduct this two events together, first sprint review and followed by sprint retrospective, given stakeholders had the option to drop off when we kick off sprint retrospective.

That "option" is blurring focus. Stakeholders have a stake in the Product. A stakeholder may be invited to the Sprint Review if the Scrum Team considers them key, such that their input is likely to prove helpful when inspecting and adapting the Product Backlog. You wouldn't expect stakeholders to be present at a Sprint Retrospective.

Hi Anand Balakrishnan, thank you for taking time and sharing your views.

Yes in my case, we welcome stakeholders to be part of retrospective and our team is absolutely no issue, so basically encouraging them to be there and share their obsevation.

And hence we are happy to combine in my case.