Teams have people, those people own work, and they have a process to complete that work. As such, Teams in Clubhouse contain Users, own Stories and Epics, and can run Iterations. By providing this thread between people, work, and process, Teams provides a strong foundation to organize around within Clubhouse.
But... how? And why? If Clubhouse is already working well for you and you have a ton of people or data that you don't really want to think about moving around, what's the best way to go about bringing Teams into the mix?
Learn all about this by watching our Teams workshop below and/or reading the summary of the workshop found below that.
We like to think of Teams as an organized and effective way to align Clubhouse to the way you and your team like to work IRL. Teams empower you to:
To get started, you simply need to create a Team and then Create (or Edit) a Story to add to that Team. This is so easy it can be done in this 12 second gif:
When Stories or Epics are labeled in this way, you can then measure progress in a variety of ways:
On the Epics page:
On the Stories page you can create a Space and filter by Team to zoom in.
On the Roadmap you can view by Team
And under Reports you can view progress by team.
See our Teams launch blog post to learn more about getting started.
But why and how should you be using it?
Below are some of the key discussions we had during the workshop. This doesn’t include all questions. If you want to get the full detail, watch the video above.
We designed "Teams" to be the default and most powerful way to organize work by Team in Clubhouse. This is only the beginning for Teams and it will be a foundational element that Clubhouse will be built around as we continue to grow. As it grows it will take on functionality that is currently scattered around a few different other features (like Projects).
Clubhouse Teams should be modeled around however your company organizes people+work (aka, how you organize your teams). Much like in your org, your Team is a group of people who collaborate on work towards a common objective.
Teams are flexible to fit various structures and sizes:
Start just by setting them up. They can just be there existing without you necessarily needing to immediately add or migrate work.
Then determine if you want to migrate old Stories and how far back you’d like to go. Our Bulk Edit options should make most of this work fairly quick.
Of course, before you do anything be sure to inform your entire organization. Best if everybody is onboard before you begin organizing new work around Teams.
We’re building the ability to remove Projects and this option is not too far over the horizon. In the meantime, here’s what we suggest:
In the short terms, that completely depends on how you want your Teams to work:
The Team-to-Workflow relationship is coming soon, though, as noted in the last answer. So this won’t require quite so much thought in the near future.
No, but we recommend you hop-on for the journey. We know functionality may be missing for an immediate transition. Specifically:
But we’ll deal with both these pieces soon enough, and we’ll continue exploring more migration support and documentation.
As of now, the way the Epic and Story associations work in Clubhouse is that a single Team can be assigned to an Epic or a Story. That means the Team field in an Epic can only contain a single Team, but within Team A's Epic, you can include Stories from both Team A and Team B that are working towards the completion of that Epic. The Stories themselves have to go to a single Team, but within an Epic, you can have both A and B Stories within Team A's Epic.
We actually have five or six different cross-functional squads here at Clubhouse, and those are our Teams. I would say four to five of them are product-focused and have embedded product managers and designers on the Teams. Those are the primary Teams that we have in Clubhouse. We also have our Projects as Frontend or Backend. That allows us to see all of the Frontend work across all the Teams, all the Backend work across all the Teams.
We also do have a few other Teams created, for the Success Team, for the Support Team, for the Marketing Team, to track some of their work. Oftentimes, they are collaborating with these squads. Whether it's the Growth Squad or-- We have what we call a Key Workflow Squad here. They could be collaborating with the Marketing Team on certain initiatives.
A very small thing that’s been a big game-changer for us, is you can also @ mention Teams in comments and descriptions. It's been really powerful in terms of cross-functional visibility when Product is asking another team for feedback, or to validate something, or Engineering's letting us CX know a bug fix has been deployed… to be able to @ mention our entire Team in just one fell swoop and everyone gets that information has been very valuable.
We don't have a great solution for this in place (yet). There are two unpopular answers that I'll walk through:
The first one is to use our API. You can always, if you have the engineering support, go in and remap your Stories and Projects from one Workspace to another one, and then find use the bulk edit option to move Stories to the appropriate Teams.
The other way is to just find a cutoff point to create a Team in the new Workspace that you want to transition to, and start doing your work there, then use the old one as historical reference. There'll probably be a few high-priority, very in-progress Stories that you'll have to manually recreate, but if you're okay with just the context switching with time, you'll naturally migrate to the new Workspace and need to refer to the old stuff less and less.
The good news is that this use case is completely on our radar. We're building this feature, we're aware of it, and it's something that we hope to have a better solution for in the future.
To see all the questions from this workshop, watch the video at the top of this post. And to learn more about Teams, see the blog post about our launch.