Best practices for managing cross-project sprints

[Esther Strom]

We ran into an issue today, and did find the answer, but I'm opening this as a discussion because I know there must be a best practice, or at least a better way.

We have multiple projects running at any given time, but they are all on the same sprint and release cycles. Our PM/BA team doesn't want to have to create a Sprint 10 (for example) in a dozen separate projects, so what they started doing is creating a sprint in one project, then using that same sprint in all of the others. This is great, except that they aren't managing the projects from a single unified board; they're each creating their own boards in their own projects. That results in the issue we had today, where someone tried to close a sprint and was asked by Jira if they wanted to move the unresolved issues into the next sprint. The PM was confused, because they didn't see any unresolved issues in their board; it turned out the issues were from another project that they weren't displaying on their board.

One thought I had, which is a major kludge, is to have a separate project called Sprints. That project wouldn't have any issues of its own. All sprints would be created in that project, and there would be a single backlog and active sprint board that would combine issues from all projects. Each PM/BA could maintain their own boards in their own projects to monitor progress and move issues towards completion, but the actual sprints would be managed by a single PM and closed by that same PM. That way, we'd avoid the issue that occurred today.

What are all of your thoughts on this? Is there a better way? (We do have Portfolio, but we're not great about estimating yet, and it's kind of overwhelming. At this point, it also feels like swatting a fly with a Cadillac - a bit overkill, based on our needs.)

[James Bullock]

Hi Esther,

You are having what they call "impedence mismatch." Honest-to-SCRUM sprints belong to, and within, a team, product and project. Jira, which implements sprints as they are defined, doesn't do this other thing directly. Try this:

• Make the darn sprints in each project's internal tools (Jira). How hard is that? (There are some other benefits beyond avoiding the cross-project completion blockage.)
• Admit you are doing some other, cross-team synch, ship, integrate, push, or something.
• Manage that other thing at that granularity.
  • Start with a bare-bones Kanban with a sequence like: "scoped", "sprinting", "ready", "integrated" & "pushed"; sprints within each project as the single-piece workflow. Tape on a wall and sticky-notes is good enough to start.

That's a candidate solution design. The people solution is you gotta get the people using the tools together in a room to agree what each thing means, and how they're gonna use it. Computers are too literal-minded to treat a "sprint" as one kind of thing one minute, and a different kind of thing the next.

[Esther Strom]

I agree that what we're doing isn't "pure" Agile, but I can't believe that we're the only team that works this way.

I also agree that it's not hard to create a sprint in each project. The difficult part is when project managers are managing more than one project - they are unable to get a complete overview of what all of their teams are doing at a given time without being able to do cross-project sprints.

[James Bullock]

It isn't just you. Exactlly your situation is why the aggregate "Agile" prescriptions emerged: "Scrum of Scrums" early on, SAFE, and whatever the branding is now. It's as old as building things: once the problem is big enough that you have to split it up, now you have an integration and coordination problem.

Concretely, there is no solution to "isolated chunks" and "aggregate" at the same time with the same thing; only trade-offs.

Refine your requirements a bit and it'll get clear which trade-offs you prefer.

[Daniel Brvnišťan]

One way of doing this is to have one common Sprint board for all the projects, in which you create and manage sprints. You include all the projects in the board's JQL filter.

For each team, you then can create a quick filter - project = A, project = B, etc.

Each team can then view their backlog by going to this filtered board, as opposed to their own board - the only difference is in the URL, what they see is exactly the same. Perhaps with a bit more quick filters.

You can still create additional boards per team for looking at the current sprint, just make an agreement between the individual POs/SMs don't manage sprints there.

The common board and sprints would ideally be managed by the overall PM/RM, restricting the admin rights.

If the release management and cross-team coordination is done by a distinct team / person that is not part of the teams, you may create a dedicated Release Management etc. project, included in the common board.

[Kunal.Solanki]

Hi Esther Strom,

We are in similar situation so if we go with a separate project called Sprints approach as you outlined above, is there any impacts to the reports if we do that and how is this working for your teams. 

I thank you in advance for your response. 

Regards, 

Kun