What is bad to have sprint review before finishing sprint?



  • I just joined a new team, their habit is : sprints of 2 weeks, but, reviews and retrospetives are not in the last day sprint, when they do this ceremonies, they still have half a day of developing and working,then in the afternoon they have sprint planning then they start new sprint !

    According to the scrum guide (or just to logic) this is wrong, it means we do reviews and we still have tasks in progress so we do not speak about them and maybe they are almost done.. so far this is my argument as a scrum master to make them change and accept the idea of : review, retrospective, sprint planning, new sprint. What else is a good argument ?



  • There's no requirement that the Scrum events that bookend a Sprint - the Sprint Review, Sprint Retrospective, and the next Sprint's Sprint Planning - all happen consecutively. Especially for the Sprint Review, it's important to schedule that at a time where the key stakeholders are able to be present and participate to synchronize and coordinate with the Scrum Team. For the Scrum Team, having all of the events consecutively can be grueling and tiring, considering the maximum timeboxes of 4 hours for Sprint Review, 3 hours for Sprint Retrospective, and 8 hours for Sprint Planning.

    There is value in having time for the team. Ideally, I try to have this time fall between Sprint Retrospective and Sprint Planning. However, this time isn't for development, but rather refinement. The Sprint Review and the Sprint Retrospective can generate work for the team. At the Sprint Review, the Product Backlog is adjusted, which may result in unrefined Product Backlog Items being moved up or new Product Backlog Items being added. At the Sprint Retrospective, the team identifies changes and improvements that may require effort to implement. Spending time to refine the post-Sprint Review Product Backlog and the improvements from the Sprint Retrospective would be a good use of the team's time and make the upcoming Sprint Planning more effective.

    Beyond refinement, holding time for non-developmental work at the time around the boundaries of a Sprint can help the team include overhead activities (like company-mandated training) or just take some regularly time off to help the team maintain a sustainable pace (a principle of Agile Software Development).

    In your particular case, if I were coaching the team, I would suggest that the team build their Sprint plans around making sure that the Sprint Goal is achieved prior to the Sprint Review. Any other work that will be done within the Sprint should also be done prior to the Sprint Review. Any time outside of the Scrum events between the end of the Sprint Review and the start of the Sprint Planning session would not be on building the product. Instead, I'd suggest that the team focus on refinement, training, skill building, or resting.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2