Every software team works differently, yet developers, designers, product managers, and QA engineers often need to work from a common set of GitHub Issues.
Workspaces provide teams with complete control over their workflows. From now on, every team from development through product, design, QA, to BI and data sciences can create their own Board and pipelines while working off the same repos. Turn your single ‘monoboard’, with its numerous pipelines accommodating every team’s workflow, into multiple Workspaces with issues and epics that are relevant to the individual teams.
Below are the most common use cases for Workspaces. Already know how you want to use Workspaces? Get started creating your first Workspace!
FLEXIBILITY OF DIFFERENT WORKFLOWS
Every pod can have its own workflow
Software teams often work out of the same repos and while they share a single codebase, each team may have a different composition, follow a different Agile methodology, and therefore require a different order and set of pipelines.
Workspaces allow individual teams to work on the same set of issues but follow their own workflow. Teams broken down into pods and organizations with multiple development teams can now create a Workspace with pipelines that reflect their actual process and methodology.
Ensure efficient hand-offs between team Workspaces
Workflows between team Workspaces allows teams to automate the movement of Issues between different Workspaces. As an issue is worked on by different parts of the team, there’s typically a number of handoffs that happen (eg. design to development, development to QA). Each handoff represents an opportunity for delays to happen if the status of an issue isn’t up to date. Workflows between Workspace allows the movement of issues in one workspace to trigger the movement of Issues in a connected workspace. Example: If an Issue is moved from “in-progress” to “ready for QA” on the development team’s workspace, it can trigger the movement of that same issue from “to be triaged” to “backlog” on the QA team’s board, signalling the Issue is ready for review.
Multiple teams can work on the same issues and epics concurrently
Issues don’t always pass through the workflow in a linear manner. There is often an overlap that might require multiple teams to work on the same issue or epic concurrently. The development team may start working on the architecture of a new feature while the design team is making final tweaks to the designs. Frontend and backend development can be done independently yet captured in the same issue or epic.
As a product owner, project manager, or scrum master you will always know the status of the issue across multiple Workspaces by glancing through the pipeline allocation (e.g. “Sprint backlog” in the Frontend Workspace, “In development” in the Backend Workspace, “Design complete” in the Design & UX Workspace).
Include business teams in your software workflow
In order to improve transparency and collaboration across different areas of the organization, link your development and QA Workspaces with Marketing, PR, or Content Workspaces. Business teams responsible for launching new products and features can conveniently access Issues and Epics that have been completed allowing them to coordinate efforts across different areas of the business.
Declutter your development Workspace from bugs
Leverage your ZenHub Board for bug tracking and triaging. When combining Workspaces and label filtering, you can capture all bugs in a Workspace designed for QA then assign them to the right team. Each team can add the issue into their own individual Workspace and resolve the bug without disrupting the workflow of other teams. You are also able to sync the pipeline state of an issue in multiple Workspaces by using ZenHub Workflows.
Collaborate with contractors and across distributed teams
Distributed teams as well as teams outsourcing their work have the flexibility to customize their Workspace without compromising access to sensitive repos. Contractors can easily follow their own workflow without disrupting the core teams. Your HQ as well as the remote teams can set up workflows to suit their needs while still pointing to the same codebase. Product managers get the visibility into the progress and status by simply accessing individual Workspaces.
Separate goal planning from sprint planning
Product managers can now create a Product Planning Workspace to group issues and epics under corresponding business drivers and organizational goals. The Board then acts as a visualization for how each issue maps back to overarching initiatives and the progress of each area.
Instant access to any team’s Workspace
Navigate through your teams’ Workspaces and see the status of all issues and epics with the click of a button. Instead of filtering out Issues on a single ‘monoboard’ in order to see Issues applicable to a particular team or a project, break your work into Workspaces and easily access status and progress of each area to gain full visibility.
