What are the pros and cons of starting and closing the sprint on same day?

[Sanjog Sigdel]

I'm a SAFe certifies Scrum Master who worked as a Scrum Master in a HealthCare IT company that follows SAFe version 5. I recently switched a new organization which is small and emerging. I'm working as a Scrum Master and I am finding things overwhelming.

The release day, sprint closure, planning and starting of new sprint all falls in same day. I have identified following cons so far:-

1. While team should be working on new sprint team is working on the deployment. This is hampering new sprint.

2. The tickets are also not marked as done/released for which the Sprint is also not closed unless tickets are deployed and done.

Is this the same scenario in your company? I've plans to mitigate this gap based on my previous experience guided by SAFe. But I want to hear suggestions from fellow community members who have worked as Scrum Master/Project Manager.

Note:- Sprint duration is of two working weeks. The day when sprint closes and the next sprint starts is the same day

Thank You

[Nic Brough -Adaptavist- · Accepted solution]

I don't think there's any negatives of having one sprint end on one day and the next sprint start the same day.

Most Scrum teams I've worked in or with do it, but with some variations.  

Most have a routine which is broadly

• close the sprint
• do the retro
• (sometimes) have lunch
• have a chat about whether the backlog is refined well enough to populate the next one (doing some refinement if not)
• start the next one

It's usually spread through the day, but it is not rare that some teams end and start the next sprint at the end of the retrospective.  

[Jens Schumacher · Accepted solution]

Hi @Sanjog Sigdel 


Most teams i've worked with closed the previous and opened the next sprint on the same day. I didn't find that to be a problem. 

What you might want to evaluate are the processes within the sprint. Are you deploying once or multiple times per sprint? What's the cycle time of tasks etc. 

Assuming multiple times, there will likely be a few tickets that spill over into the next sprint. But that's ok, as it will normalise over time (eg. most sprints might have some "spill over" that gets closed off at the beginning of the next sprint). 

Ultimately you want want is consistency between the sprints, to get meaningful velocity data the ability to improve your processes. 

You also mentioned that this is a smaller team. So it's important to be mindful and understand that some of the processes that benefit larger teams, might just create overhead for a smaller team. 

[Sanjog Sigdel]

Thank You. The answer is convincing. Accepting the answer.

[Fabio Racobaldo _Herzum_ · Accepted solution]

Hi @Sanjog Sigdel and welcome,

I'm SAFE scrum master certified too but, in my experience, I never heard about a one day sprint. In that scenario, agile ceremonies could be longer that the work itself.

My suggestion is to try to apply Kanban approach with a backlog (https://support.atlassian.com/jira-software-cloud/docs/use-your-kanban-backlog/). At the start of each day, team and PO defines which tasks should be "selected for development" and go ahead with work.

A one day scrum, in my mind, is not a real scrum.

Fabio

[Sanjog Sigdel]

Oh, sorry for the confusion.

Sprint duration is of two working weeks. The day when sprint closes and the next sprint starts is the same day. My question was to understand what are the positive and negative aspect of keeping the date when sprint closes, and the next sprint starts is the same.