What Order Should Sprint Meetings Be In?

I had an interesting conversation recently regarding the order of sprint meetings, and whether it mattered what order the review and retrospective took place.  This lead to a wider conversation about whether you could do review, retrospective and planning in only 1 or possibly 2 meetings.  That all sounded a bit "dirty agile" to me, which is normally a good cue to re-examine my assumptions to see if I've been thinking too rigidly.

In my head, the sprint ceremony order is one of the inviolable "rules" of scrum, so much so that it didn't really occur to me that people might think differently.  It's just one of the default assumptions I have about how scrum is done, rather than a subject for debate.  After discussing the matter I still don't think this is something about which you can be flexible, although this is not stubbornness so much as the lack of a compelling argument to the contrary. I'm open to persuasion if such an argument exists though.

The agile mantra of "Inspect and adapt" is high on my list of principles, so to that end I'll lay out the order of sprint meetings and why they need to be discrete meetings, and if anyone wants to chip in with counter suggestions I'm all ears.

First, the facts as I see them:

1. The Review should happen on the last day of the sprint.
2. The Retrospective should happen on the last day of the sprint.
3. The Retrospective should take place after the Review.
4. There should be a break between the Review and Retrospective of at least an hour.
5. The Planning should happen on the first day of the next sprint.  
6. The Planning for the next sprint should never happen until the Review and Retrospective from the previous sprint have been completed.

And now the justification for each of those points: 
 
1. The Review can only happen once all of the sprint stories have been completed and not before.  Therefore the Review needs to happen at the end of the sprint.  If all of the stories in the sprint have been completed before the end of the sprint then either additional stories can be added - if there's adequate time to complete them before the end of the sprint - or the team can groom the backlog, triage support requests, refactor code, and any other tasks that don't impact the sprint velocity. (If a task impacted the sprint velocity it would be story-pointed and as such be a story that was added to the sprint.) 

The Review will already be a recurring appointment in the stakeholders' calendars and as stakeholders are often in demand it shouldn't be assumed that bringing the Review forward will be simple case of sending out an updated appointment.  This is especially true where stakeholders are many and/or senior.  But this a practical objection, albeit a sensible one, and as such doesn't have the force of compulsion.  The compulsion should lie in the fact that moving the review forward serves no purpose. Assume that the Review is moved forward.  Either the Retrospective is moved forward as well or it is not.  If the Retrospective is not moved forward then moving the Review has served no purpose because the team still has to wait for the Retrospective. If the Retrospective is moved forwards as well then the end of the sprint must be moved forward, otherwise the team will have to wait for that instead.  If the end of the sprint is moved then the next sprint must be started.  This means that your sprint will start on a sub-optimal day.  Any teams working on the same sprint cycle will now be on a different sprint cycle.  The team's velocity calculations will no longer be valid.  Your customers - assuming you release an increment at the end of each sprint - will have to change their processes to accommodate a different cycle. There are other issues that will arise depending on circumstances, but all of them revolve around disturbing the cadence and rhythm of the sprint cycle. Scrum is predicated on having this cycle as part of the methodology for successful teams; there appears to be no benefit to disturbing it.


2. Assuming that the arguments for the timing of the Review ceremony hold, the same will apply to the Retrospective.  Therefore let's look at the order of the Review and Retrospective meetings.


 3. There is an argument that holding the Retrospective before the Review allows the team to deal with what went wrong and then finish the sprint on a good note with the Review where they can show off their work to the stakeholders.  I like the sentiment, but not the logic.  The argument hinges on 2 unfounded assumptions, namely that the Retrospective is all about what went wrong and therefore is a necessarily less than enjoyable meeting, and that the Review will always go well.  Neither of these assumptions stand up to scrutiny, regardless of personal experience.  That's not to say that for some people Retrospectives are a generally unpleasant experience, nor to suggest that every team has had a Review that didn't go well. But my assertion is firstly that a Retrospective should neither focus purely on what went wrong, nor be an unpleasant experience, and secondly that the assumption of future Review success based on past glories is hubris that will inevitably bite the team at some point in the future.

The long and the short of it is that the Retrospective should be honest but not unpleasant.  It's true that if you are the kind of person who doesn't take criticism well then you might not like hearing that something you were responsible for didn't go well, but frankly that's your problem and you owe your team a more mature attitude.  Likewise, if there is a team member who revels in shoving failure down the throats of their team-mates that's not pleasant either, but the group should combine to shut that person down (or in extremis remove them from the team).  Being part of a scrum team means learning and growing through an iterative process. You have to be open to that.

Likewise, Reviews can go wrong.  More importantly, they can teach you things you didn't know if you have active stakeholder participation (which you should have!). Either way, the Retrospective is where these things should be discussed and actions created.  This can only happen if the Retrospective happens after the Review.


 4. Ok, fine, we do the Review then the Retrospective.  We'll do them in one meeting and get it all out of the way, ok? No, not ok.  The Retrospective should be a separate meeting, because what comes out of the Review needs to be thought about before having the Retrospective.  Also, people work better when they've had a break, and the Review can be tiring if you've got a lot of questions to answer from stakeholders.  Give people a break for an hour or two, let the Review comments sink in, then do the Retrospective.  You'll all get more out of it that way


 5 If points 1 - 3 are assumed, then the timing of the Planning meeting becomes self-evident.  You can't complete any stories unless you've got stories to work on, and to get your stories you need to have a Planning meeting.


 6 Well, why can't we plan our next sprint if we've got some spare time? Because actions will come out of the Retrospective, and quite possibly the Review, and these should be captured in your task management system and might need to go into the next sprint.  You can groom items on the backlog, and that includes estimating story points and task time, but you won't know what the final priorities are until all of the previous sprint has been completed and the Product Owner has updated the backlog with the latest priorities.


Hopefully that explanation provides solid reasoning for you, but don't be afraid to drop a comment below if you disagree!