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.

  • 10
    If each member of the team has their own project, it doesn't sound like you actually have a Team! This is what I would call a group of individuals, and is very different; it's certainly not a Scrum Team. Nov 4, 2021 at 14:24
  • I wonder if you work at the same company I worked at for 1 month... Nov 5, 2021 at 13:46

2 Answers 2


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.


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.

  • Thanks for the feedback! So, a bit more context here the Scrum team that I have has the following people: Product Owner, Scrum Master and Developers. All of the Scrum team is part of developing a product and each of the team members (developers) in this context share the common knowledge in developing this application. But this application is quite customizable and this additional layer of customization is modified as per the need basis for an end user. So, different team members would be working on different end user's customization functionality with each having their own PM's.
    – Srikar
    Nov 4, 2021 at 15:23
  • 5
    @Srikar That still doesn't sound like a Scrum Team. I see no evidence of a Product Goal, a Sprint Goal, or a cohesive unit of professionals. I see individuals working independently.
    – Thomas Owens
    Nov 4, 2021 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.