Sprint Manangement Across Workspaces

After watching most of the very useful YouTube videos on using ZenHub, I set up multiple Workspaces very similar to the way George did in the video entitled ZenHub Deep Dive: Automated Workflows for Team Workspaces. Specifically, I created three workspaces for our Frontend scrum team:

  • Frontend: Refinement
  • Frontend: Sprint Planning
  • Frontend: Current Sprint

After creating all of the workspaces and workflows, I created a few issues and moved them through the system to the Current Sprint workspace. While in that workspace, I configured sprints thinking that it applied to all workspaces, but to my surprise it does not. Sprint configuration only has scope for a single workspace.

I understand from ZenHub support that “Workspaces were designed to be the home for a Team, the thinking is that we wouldn’t want one team to override the issue order of another team”. However, it’s not clear to me how that philosophy works in the YouTube example where the Team Watney scrum team has three separate workflows for refinement, planning, and current sprint. In the deep dive video, George is able to set the sprint in the Sprint Planning workspace (25:50m mark) by setting a milestone. I’ve only known Board 2.0, but I have a feeling that the GitHub Milestone feature was key to allowing sprint assignments across workspaces, and ZenHub no longer supports them, right? This multi-workspace model works for our team, but not if each workspace has independent sprints.

All of the organizations that I’m aware of march to a common sprint cadence. Though I appreciate the idea of allowing teams to optionally configure their own sprints, I do think we need the ability to share sprint configurations across ZenHub workspaces. For example, we want the ability to assign issues to sprints during the refinement/planning phase, not in the current sprint workspace.

The only workaround I see is to merge all three of our workspaces into a single workspace named Frontend. This is not ideal, but will have to do it if there are not other options.


  1. Did I accurately describe the current ZenHub sprint-workspace behavior?
  2. Are their other workarounds that would allow us to have multiple workspaces for a single team using a common sprint cadence?

Thank you,

1 Like

Hi Peter!
Julie here :wave::smiling_face:
You got this right- workspaces are per team, and sprints are per workspace. In the videos from George (I just went back and realized I’m in that video too :joy:) the automated ZenHub sprints feature hadn’t come into the tool yet. At that time, back in 2020, teams were manually tracking their sprints with GitHub milestones, which also lacked visibility with specific team reporting. While we don’t support milestones in Board 2.0, our product team is looking into ways to have the concept of cross-workspace sprints, while maintaining the ability to have workspace (scrum team) specific reporting.

Hi Julie

I am sort of having the same problem, just not with sprints, but at a higher level with Now > Next > Later. Where I think the solution could be multiple boards in the same workspace, could that solve the problem with the sprints as well?

And could that be an option you could look into?

Regards, Kenneth

1 Like

Hi Kenneth,
Ah we don’t have multiple boards in a workspace; the ratio is 1:1, but that is something the product team could investigate!
If you are keen to book a coaching session with us, we can help talk through some options: Calendly - ZenHub Customer Success


1 Like

trudog - I also would like to be able to synchronize sprints across workspaces. For me this would be super useful as I have three workspaces at my company, a Management Workspace for planning sprints and managing the backlog, a Developer Workspace for developers to work on items in the current sprint and advance to QA Ready, and a QA/Release Management workspace where QA manages the testing and rework requests as well as advancing to Release Ready. Whenever I need to add or remove an item from a sprint, I need to visit each workspace and synchronize the issues associated with that sprint - this is sub-optimal. Thanks for pointing this out.