You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.)
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.
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.
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.