The Hipchat team went from one team in San Francisco to multiple teams across four time zones before anyone could blink – let alone think about how hard it is to pull that off.

Josh Devenny (Hipchat Product Manager, San Francisco) and Dave Minnigerode (Hipchat Development Manager, Austin) gave a great webinar about how they manage Hipchat’s distributed teams of engineers, designers, and contractors. Check out the recording below. And below that, you’ll find a transcription of some Q&As that dive deeper into the challenges of scaling globally: getting on the same page about work status, enforcing protocols and process with contractors, and collecting end-user feedback.

Watch the webinar now

Top Q&As

Here, Dave and Josh answered the most common questions from the Q&A sessions held between three different audiences. Some answers are personal preferences and others are pro tips for users of Atlassian tools. Dig in!

Q1: How do you plan releases across various teams and locations?

Dave: Ideally you’ll have one releasable entity per project. Then I like to have the fixVersion set for all the issues we plan to have in a particular release, you can then see release burndowns with the Jira reports. I also add a fixVersion quick filter to the board so it’s easy to see what is currently in/out of a given release. This works for both iteration and backlog views.

Josh: What Dave said.

Q2: How do you distribute/plan/align development work across all various teams and locations?


  1. Have a high level strategy that spans the entire team
  2. Break your strategy down into initiatives
  3. Break each initiative into a set of projects and a set of OKRs (objectives & key results)
  4. Organize each team around the strategy and assign them a few KRs or objectives that they need to deliver on

Q3: We also have teams spread out globally, and we have some teams giving feedback only. How do we keep this feedback separate from our sprint itself? Should we create issues in a separate board or create custom issues within the same board for this?

Dave: You can do this a couple of different ways:

  • Use a new Jira issue type called ‘Feedback’ that can include in epics, links, but not include on a particular board filter. Also use quickfilters here.
  • Use a label, which you can filter in/out of a board with a quick filter.

Josh: For Hipchat we use a separate Jira project called “Feedback”, and all of our feedback comes through that. We can hand-select which pieces of feedback make it across to the Hipchat project where we do all of our development.

Q4: What are other ways and methods that you use to shorten the feedback loop?

Josh: Create a feedback loop before you ship. Get feedback on sketches, early thoughts, mockups, prototypes, alphas, everything! Talk to your users! Make sure that you’re constantly getting feedback throughout the entire process.

  • We use the issue collector a lot in our alphas and betas.
  • We collect analytics from everything we do.
  • We talk to users about our designs/sketches/thoughts to see what they think before we’ve built anything.
  • We allow engineers to take “20% time” to prototype any ideas that they have and then test them internally and with customers

Q5: Do you split your backlogs by product feature? Or some other way, like by platform?

Dave: We typically use one epic per feature. This allows you to use the backlog view to plan particular features in a given iteration in Jira. That is, select the epic for a feature in the backlog view and you can see what is in the backlog and in the iteration. It’s easy to move stories as needed just for that feature. Then select another feature and do the same.

Josh: What Dave said, but there are multiple backlogs across Hipchat. And sometimes a team is working on multiple epics at the same time. We utilize filters + components + custom fields in Jira to make sure each board accurately reflects the set of work a given team is working on.

Q6: When working with vendors, do the vendors fully use your instances of the tools, or do they have their own installations of Jira, Bitbucket and Hipchat ?

Josh: They have repositories in the Hipchat account on Bitbucket, which they have full access to. We also created a separate, shared account in Hipchat so that we can all chat there.

They use our instance of Jira, but a separate project space (which everyone in Hipchat and the contractor has access to).

Q7: Do you have any tips for using Hipchat for resolving technical issues (network operations center type triage)?

Dave: We open a separate room for a ticket when that ticket is created (using the new Jira/Hipchat integrations). So all discussions occur there while docs end up on the ticket. The subject for the room has a link directly to the Jira issue.

Josh: Yep, we use it for a ton of things:

  • Ops issues are filed under our HOT (Hosted Ops Team) project in Jira, and then a Hipchat room is created for that HOT issue
    • Everyone that’s required to help out is in that room and listens to all updates. If it’s a really sensitive issue we will make the room private in Hipchat.
    • Each time a Jira issue is mentioned in the room, a summary will automatically be brought back to the room.
    • Each time the issue is mentioned in another room, the main HOT room is pinged with a message saying that someone else has asked about the HOT issue (“Hipchat Discussions” feature).
    • More info here on Jira and Hipchat integration
    • Or more info on the PagerDuty integration and the integration

Q8: Which, if any, of the “bots” being mentioned are either included in Hipchat or available as add-ons? I.e. How many are not just internal to Atlassian?

Dave: You can setup your own bot at any hosting service you like. Cloning existing bots from the bot lab is a good way to start.

Josh: Here are a few bot resources to help get you started.

Q9: Your example about the “/standup” command… if users enter that tag at the start of their chat, does Hipchat automatically compile the status on one conversation? Does it know the standup is for today vs. the previous day? How does this work?

Dave: The standup feature is just another bot. So the bot is responsible for storing the current state of the standup. You can view the source code at:

Q10: Do you find that content gets buried in one Hipchat room, but folks are looking in other rooms to find the relevant content? With all the rooms you can create, seems like this would be an issue.

Dave: Things that need to be kept around longer belong in Jira or Confluence. Hipchat history for single topic rooms can be useful, but it’s usually impractical to go back more than a few days.

Josh: This generally leads to content being stored in Confluence or people splitting into separate Hipchat rooms to discuss more specific content.

Hipchat is also working on a feature called “per room notifications” which allows you to choose what level of notifications Hipchat pings you about on a per room basis (sometimes you want to listen to everything in a specific room, other times you don’t want to listen to anything and just be passive).


As you can see, the Hipchat team relies heavily on Jira to track their work and stay organized. See for yourself how Jira can help your team with a free, full-feature trial.

Try Jira for free

Webinar recap: How Hipchat went global using Atlas...