Is one sprint across multiple projects good/best practice?

[Phil]

Hi all, 

I have 5 teams that work together each month in a 4 week sprint to deliver work for ~20 projects (clients). 

At the moment each project has its own sprint (and we use rapid boards to view tasks at aggregate level).

This works but seems to have limitations (particularly in relation to advanced roadmaps and capacity planning).

Would it actually be better to put all tasks from all projects into one global sprint? 

I still need to be able to easily measure the number of points per project in each sprint, and report on the points done. 

Appreciate your thoughts/opinions.

[Walter Buggenhout]

Hi @Phil,

While this is not a yes/no or black/white or right/wrong question, a sprint is usually run by a team. Some teams only run a single project and others run several in parallel. The most common scenario I usually recommend is to run a single sprint per team, regardless of where the work is coming from. A big advantage is that your teams then have a single place to plan and track their work.

Usually, teams are formed around a common practice, customer or tech stack anyway. Which also helps in determining the team velocity.

Hope this helps! 

[Phil]

Thanks @Walter Buggenhout 

I'm interested in what you say about having a team's work in one sprint, regardless of where (presumably/hopefully you mean which project) its coming from. 

Trying to think what this would look like from a sprint/project planning perspective. 

In each project (client) we would have tasks to be assigned to each team's sprint - I'm wondering what the workflow for that is? Can you share any more advice?

And where would that team-specific sprint live? Would it be best to create a project for that?

[Walter Buggenhout]

Hi @Phil,

A(n) (agile) team is a group of people that works together on shared goals / a shared backlog, right? In some cases, a team is dedicated to a single project for a long time, in which case team / project planning is basically the same thing. No issue there.

Complexity starts when teams work across multiple projects. They become a shared resource of multiple stakeholders, all with their own priorities and deadlines. Sh@#!t then usually hits the fan when those stakeholders do not have processes or practices in place to take joint priority decisions (which is sometimes perfectly normal when they are e.g. not part of the same company).

In the end, a team should plan its own sprints. But it does need the information of its stakeholders to make reliable priority decisions. That usually means that project/product owners, business analysts etc. should have a clear practice to deliver work to the team that is ready for development.

From a configuration point of view, you could add the R&D / Analysis steps to prepare the issues for development to your story workflows. Let analysis teams work through the requirements stage from a kanban board and only let issues appear on the dev team's scrum board when they meet the definition of done (e.g. linked to the status Ready for Development). As soon as issues appear on the dev team's board, it's that teams responsibility to add them to the proper sprint in due time. Having PM's attend the sprint planning meeting(s) may be helpful to have their voice be heard.

In terms of where the team board should live, I am with you. While a project actually ends at some point, the team lives on. For that reason we often set up a team project in Jira for the main purpose to just host the team scrum or kanban board(s).