Sprint Planning before Review

I have had almost the exact situation occur. What I did was have the events in order but I shortened them all from the normal duration. We cut them all in half for this one time. We were successful in finishing all of the events but we found that there was some followup activity needed for both Review and Planning. Let me explain that.

In our Review we were able to cover all of the work that had been done but some of it was superficial. So we all agreed to get back together at a point during the Sprint when the Development Team and Stakeholders were available and go a bit more in depth on a few of the items. Any discovery from that went directly into the Product Backlog. We all agreed it wasn't ideal but it was better than not doing.  But there was a good thing that came out of it.  The Stakeholders and Development Team decided that in order to prevent something like this from happening again, they started to work closer together during the Sprint. The Development Team would have a Stakeholder sit with them and discuss things anytime a "is this the right thing" question came up.  It brought a tear this Scrum Master's eye when it was their decision and not something I suggested. 

During the Planning session, the Development Team and PO discussed the fact that there could be something that came out of the "Review part two" that might be considered more important than anything that they had pulled in.  Since the PO was going to be unavailable during the first part of the Sprint the Development Team put together a Sprint Backlog that was lighter than normal to allow for some extra stories to be added.  They also discussed with the PO which of the stories they put into the Sprint Backlog were candidates to be pushed back to the Product Backlog should the need arise. This allowed the PO to participate in the discussion and provide guidance on importance of stories before they became unavailable.  This actually worked well.  So well that the Scrum Team has used this practice on more than one occasion when there are still some uncertainty due to conditions outside of the teams control. 

All of the "pluses" from these were identified and discussed in the Retrospective for the "experimental" Sprint so the team already had experienced it.  In the end it turned into a great experiment. 

Good luck with yours. Come back and share what you did and the results. I would like to hear from someone else that experience this.

The biggest risk that I see is that the Sprint Review will cause a change in priorities of the stakeholders. If the Sprint Planning happens first, then the team may already have ideas and perhaps have even started working on things that are no longer relevant and a decision about what to do with this work must be made. However, you can mitigate this by ensuring a good portion of the Product Backlog is refined. As long as the change in priorities is somewhat aligned with work that has been refined, the team may have a deeper understanding of the work and can make appropriate adjustments. The Product Owner working with stakeholders before the Sprint Review and Sprint Planning to try to get the Product Backlog ordered and refined may also be beneficial.

Regardless, I would go in to the Sprint with the thinking that there is both a reduced capacity (due to holidays) and risk (from working off a Product Backlog that may not be as best aligned with stakeholder needs).

One option, and it may not work for you / your stakeholders / your organization / your team may be to reduce user facing functionality delivered in the upcoming Sprint. Perhaps you can respond to more important feedback and work on some more important functionality, but focus on things like improving the learning of the system or other kinds of technical debt paydown.

It seems like the lack of a Product Owner is the biggest issue. The reduced capacity of the Development Team can be mitigated relatively easily. This is one of my problems with the Scrum Guide as its currently written - you need redundancy in the roles to ensure that things like this don't happen. Having someone else who is able and willing to step up into the Product Owner role for a week or two can mitigate lots of problems - vacations, illnesses, the Product Owner leaving the organization.

To what extent have the team been able to review finished work continually during the Sprint?

Hi guys,

Thanks for the replies and advice. I actually have the meeting with the PO to set up the new times for the events in a little bit. I will bring your suggestions to the table as well and see what option will be the best for us this time.

I will come back and relay what we decided and once the next Sprint is over I will try to update you guys on what was the result.

Thank you once more!

Kind regards,

Victor

Hello guys,

We've decided to have the following order: Sprint Planning -> Sprint Review -> Sprint Retro. In order to limit the impact of this order, we planned for a shorter sprint, one for which we can actually plan without waste and unnecessary work. It remains to be seen whether the outcome of this exception will be the one we hope for.

Thanks again for the input and I hope we will get through this well, as a team.

Kind regards,

Victor

If you can't do it the way it should  be done, then you should do it the way it can be done.

Never dogmatically apply Scrum, or any other empirical framework for that matter. Inspect what is possible and adapt accordingly.

Sprint Planning -> Sprint Review -> Sprint Retro.

I think it's a very good decision to have the Retrospective last, as it provides opportunities to inspect the impact of switching the order of events. If switching the order of events doesn't result in any meaningful disruption, you might want to investigate whether Sprint Reviews are as helpful as they should be.

It might be that after the Sprint Review, it's discovered that the Sprint Goal isn't what is most needed. It remains an option for the Product Owner to cancel the sprint, which would lead to another Sprint Planning.