Scrum Retrospective out of sequence.
So I have a scrum team that has their Sprint Review, Sprint Retro and Sprint Planning all on the same day which happens to also be the last day of their sprints. The sprint review is done on the last day because it happens to be when all the key stakeholders are available. The Sprint Retro happens after the Sprint Review then Sprint Planning follows. This scrum team also does operational work and they feel that having all of those event in one day is time consuming as they are unable to get much operational work done on the day that all three events occur and I agree with them. The solution that they proposed was to possible have the Sprint Retro the next day after the sprint review. So that would mean that we would have the Sprint Review and Sprint planning before the retrospective. I understand their reasoning however I feel that the Sprint Retro should happen before the Sprint Planning as that is the order that the events should be in according to the scrum guide. If we do not have the Sprint Retro before the Sprint Planning then the planning would be incomplete without an element to improve upon as part of the sprint goals. I suggested that we can we can do the Sprint Retro the next day and have the Sprint Planning right after and start the sprint right after Sprint Planning at 1PM.
Sprint Review - Thursday (Last Day of Sprint)
Sprint Retro, Sprint Planning - Friday (First day of Sprint)
I used to do that very often. All of the events on a single day can make the day long. By splitting them across a night time break, it helps with the burnout from back-to-back meetings. I suggest ending a day with the Review and possibly Retro, then start the next day with Planning. That way you go from ending one sprint on Thursday (to use your example) and begin Friday with the start of the next sprint.
Remember, the only guidance that the Scrum Guide provides is that a Sprint starts when the previous ends and that the Review and Retro are events meant to end the Sprints as their purpose is to reflect on the Sprint to improve the Product Backlog and the team's ability to work together.
I suggested that we can we can do the Sprint Retro the next day and have the Sprint Planning right after and start the sprint right after Sprint Planning at 1PM.
Why are the team proposing a different arrangement?
If, during the Retrospective, the team decides to change something about the Sprint Planning, and you do planning before retro, you have already missed an opportunity.
Not only does having a Sprint Review, Sprint Retrospective, and Sprint Planning in one day take up a lot of time, but it can also be exhausting for the team. I've also found that it can shortchange the events, leading to the team trying to compress the events too much and not getting to their intended outcomes. Maybe for a 1-week Sprint, you can fit everything, but for longer Sprints, it's a lot to fit into one day.
There are very few instances where I wouldn't recommend splitting up the events across two days. I've worked with teams that split the events up into Review/Retro and Planning as well as Review and Retro/Planning. I didn't notice any huge differences, but Review/Retro on one day with Planning the next seemed to feel more natural as it was one day to "close out" or "wrap up" a Sprint and one day to "kick off" the next.
I'd also say that you're absolutely right that you need to have the Sprint Retrospective before the next Sprint Planning. Not only does the latest revision of the Scrum Guide call for this order, but you can't effectively plan without learning from your previous Sprint. Even if you didn't formally bring in an improvement item as part of your Sprint Backlog (which is no longer required), you wouldn't be able to account for the impact of process improvements, changes to the Definition of Done, or any other adjustments to the team's way of working. You'd either need to reconsider your plan (leading to wasted time and effort) or delay improvements until the next Sprint. Neither is desirable.
I understand the team would like to to move the Retrospective to the next day, and after Sprint Planning has occurred. Have I got that right?
I would not stop the team from trying it — what's the worst that could happen? I encourage experimentation and I believe strongly that team agreements are important to support.
However, before any team agreement (such as whether to practice Scrum, the sequence of their meetings, etc.) I would first:
- figure out if the proposed chance has broad support across all members of the team or perhaps just one or two people feel passionately about it.
- note the current condition (the current agreement) and have the team write down their predictions about what will happen. I mean, as a result of this adjustment to their agreements, what "good" results are likely to occur, and what unintended consequences or "bad" results may occur. It may help the team to understand whether the change is beneficial or not.
I suspect, after a few Sprints employing the new schedule of events, the team will have a new perspective and may undo the change, or adapt and try something else.
I'm curious why the team seem to want to delay the Sprint Retrospective, and not Sprint Planning.
Could it be that they don't feel they are allowed to delay Sprint Planning, but that there would be no objections in the wider organization if they postpone continuous improvement to their effectiveness?
The Sprint Review and the Retrospective meetings wrap up the end of each sprint, therefore, I would suggest having them on the last day of the sprint. I would then have your Sprint Planning the following day. I would not suggest having them all on the same day since that would be very exhausting for the team. I personally like having the Retro as the last meeting of the sprint so that the team can reflect on the full sprint, including all of the scrum ceremonies, and really think about how we can improve for the next sprint. It's good to allow them to break overnight and then they'll be more fresh to have the Sprint Planning the next day; plus you can incorporate learnings from the Retro into the next sprint. We do this at my company and it works really well.