Should we have different sprints for different projects or a single one for all proejcts?

Question

In my previous organization, there used to be separate sprints for individual projects. The common understanding was that we follow an Agile Release Train and the sprint opening and close date was constant over all ARTs.

In my new organization there is one single sprint for all scrum projects. Now one of my scrum team's release is taking more time so the sprint close will happen in next day. This is an exceptional case because of business priority in terms of value delivery. But other scrum teams can't start next sprint and estimation since the sprint is not closed.

Please educate me on the standard practice and how to handle the scenario. Should we have a single sprint or keep separate sprint for separate teams?

Sanjog Sigdel · Answer

Hi @Walter Buggenhout Your answer is intuitive. That is how we cope up with the change and yet keep the mindset of getting things done.

However, I would like some suggestions on the problem that I am facing in my team.

In my new organization there is one single sprint for all scrum projects. Now one of my scrum team's release is taking more time so the sprint close will happen in next day. This is an exceptional case because of business priority in terms of value delivery. But other scrum teams can't start next sprint and estimation since the sprint is not closed.

Thank You

Walter Buggenhout · Answer

Hi @Sanjog Sigdel and welcome to the Community!

One of the key things when it comes to agile in general, it is to have a getting things done mindset and a culture that embraces the reality of change. Everything changes all the time, so teams that are ready and willing to cope with that reality are likely to be more effective than teams that are not in that mindset.

When it comes to sprints in scrum, putting the concept of a team central is key. You have scrum teams rather than scrum projects. And so it makes sense to have a single concurrent sprint for a team, that may include work from one or several (Jira) projects. The latter depends on what the team is organised around.

Having one sprint for multiple teams is counter-intuitive, as you indicate in your question. Agility in planning and execution of a team should not be hindered by work or processes from other teams. When scaling to the enterprise (e.g. in SAFe), teams run their own sprints independently, but try to align their cadence across other teams that get grouped in release trains (ARTs). That helps them work independently, but at the same time in alignment.

Hope this helps!