Scheduling Sprint Reviews

Question

I'm trying to find the right balance on how Sprint Reviews should be scheduled for my Team. Each member in my Team has their own project although everyone in the Scrum Team does attend a single Daily Scrum. Each member has their own Sprint Planning for their project and the Sprints last for 2 weeks. The Sprint start and end times are shared among all the team members.

So, here we are trying to integrate Sprint Reviews into Sprints where they would occur every other sprint (once a month). So, there would be one Sprint Review for each team member.

Could someone suggest which would be an ideal day in the 2-week Sprint cycle for this event?

Certainly a lot of articles online suggested it to be better for it to be in the last day of the Sprint (right before the retrospective) which is great but here when there is one Sprint Review for each it might lead to too many meetings for the Scrum Master on one day with the added constraint that all of these meetings should be done before the Retrospective.

Any insight would be appreciated.

Answer 1

You are not doing Scrum, by any stretch of the imagination.

Now, there may be a good reason for that. Scrum itself does not always fit all circumstances. But I have to ask - are you not following Scrum because you first tried it (Shu), mastered it (Ha), and then customized it to meet your needs (Ri)?

Or are you not following it because you assumed you could do better from the very start?

My advice?

• Stop assigning projects to individuals. Assign them to the Team, with priorities, and let the Team figure out who does what when.
• Merge all your Planning Meetings into one
• Have a single Sprint Review Meeting every Sprint

Basically, follow the Scrum Guide. Only after you've tried that for a few months, and the Team fully understands how to do Scrum, do you then look into trying out changes such as creating sub-Teams (Highly discouraged! Beware!) or moving Sprint Reviews to be bi-Sprintly.

Answer 2

I'm going to echo Sarov - what you are doing is not Scrum. Scrum is defined in the Scrum Guide. The Scrum framework, as it's described by the Scrum Guide, is immutable, meaning that implementing only parts of Scrum results in something that is not Scrum.

The Scrum Guide describes the Scrum Team as "the fundamental unit of Scrum", but also as "a cohesive unit of professionals focused on one objective at a time". A Scrum Team consists of a Product Owner, a Scrum Master, and a small number of Developers. This doesn't exist in your context. Instead, you have a group of individuals. Since the Scrum events and artifacts are built around the idea of a Scrum Team, you'll find that they aren't effective or applicable and you'll likely struggle to see benefits.

Even assuming that you were operating in a Scrum context, having Sprint Reviews every other Sprint is not Scrum. A Sprint Review happens every Sprint and is always the second-to-last event, followed only by the Sprint Retrospective. It's the opportunity for the Scrum Team and key stakeholders to synchronize on important developments and changes that may have happened over the last Sprint.

I would suggest not looking at Scrum for guidance in what to do in your situation. Instead, identify the problem that you are trying to solve, the constraints that you are under, and try a solution. The motivations and factors of Scrum won't help you here.