We tend to do our retrospective on the final day of the sprint and have found that by the end of an hour and a half, launching into a planning session is not ideal at all.
When do you hold your sprint planning meeting to walk through the newest batch of stories and begin to work out the details so points can be estimated?
I've done retrospective and planning on the same and separate days. My preference (and it is a very slight preference) is to do both on the same day, back to back...
Spreading them across days is nice for the Scrum Master since they only need to prep one intense meeting (instead of two) but I think this isn't a huge issue. I would let the team decide and even try a few different approaches, I don't think there is anything magical about when to have the meetings, and you might find one team prefers one structure and another team prefers a different one.
I note in your question you refer to the retrospective rather than the review session. First of all, I just want to check you're not confusing the two: the review is where you demonstrate delivered backlog items to stakeholders, the retrospective is for the team to discuss and improve the process itself.
I always leave at least an overnight, and preferably a weekend, between the sprint review and the planning session. The review is when feedback and new ideas get tossed around - yes, ideally they'd already be in the backlog, but in reality this is what seems to happen. Having a good break between the two sessions gives the team (and everyone) a chance to mull over the comments and come back ready to discuss them properly.
So, ideally (and it's not always practical when you have multiple teams) I have sprint review on friday afternoon and planning on monday morning.
As for the retrospective, that tends to happen straight after the review session - but that's flexible depending on how the team is feeling and how draining/difficult the review has been. Definitely not immediately before the planning session though - if necessary I'd even rather defer it until AFTER the planning session (although that would obviously preclude improving the planning session itself!)
I usually ask my team how they would prefer to do the retrospective and planning. Usually the asnswer is on the same day as alhtough, recognising these sesisons as important, they prefer to get to the next iteration as soon as possible.
You may wish to consider things such as:
length of iteration - longer iterations will tend to lead to longer retrospective and planning sessions, which may be too long and draining to get the best value form the sessions.
team experience - experienced teams may be able to get the best value from these sessions in less time and with less strain.
product complexity - a very complex product will require more retrospective and planning time, again meaning that the sessions maybe too long.
The above is not exhaustive, the point is to examine how you do things and try and make sensible decisions that suit you and your team.
Remember, you can inspect and adapt this process too, so you can try different approaches.
I do them in the following order:
Review -- this is where we do the "show and tell" to the stakeholders.
Retrospective -- the team does this post review so we can incorporate the review feedback into the retrospective. This is a team-only meeting and I don't allow anybody else in the room. This gives us space for the sometimes frank discussions that need to occur.
Planning -- the only disadvantage of not doing the planning straight after the review is it can occasionally be difficult to get the right stakeholders in the room after they've been shoved out for the retrospective :-) But as I tell them, if you don't help us plan the next sprint, we'll do it without you.
