How to manage development tasks and bugs/issues in a small fully-remote development team?

I've just hired two developers so I need to put a system in place for managing development tasks, reporting bugs and getting them fixed. Up to now it's just been me. We are a fully remote team.

Here's my first go at creating a simple solution (see diagram below):

There are two Kanban boards, Development/Features and Support/Bugs.

The service desk will be used by our Customer Services team and the internal users to report issues/bugs to my development team. They may also use this board to add feature ideas etc.

Once on the service desk, any bugs can be moved to the backlog on the Support/Bugs Kanban board. All feature ideas are moved to the Features Kanban.

The app we are developing is used heavily within our company by most people. There is also a client part that lets them login and do things.

I'm thinking I'll use JIRA (Jira software + Jira service desk) to set this up.

Is this a good solution? Is there a better way?

Some may argue that the bugs and features should be added to the same board, as after all, they are just another development problem to be solved with code. This application runs in a highly regulated accredited laboratory environment. Bugs have a special status and should be fixed asap. I'd like a place to see any outstanding bugs and putting them with all the feature requests might make that harder.

enter image description here

  • How do you plan to manage WIP limits across multiple boards? It can be done, but you need to articulate your process better in this critical regard.
    – Todd A. Jacobs
    Jun 1, 2019 at 17:16

3 Answers 3


Apart from using two boards, your proposal will certainly work.

Having separate boards for bugs and new features is a very good way to ensure that either bugs get ignored or that new features get mis-labeled as bugs to get them implemented. You will find that in the day to day work, at least half the team will only look at one board. If you are unlucky enough to have plenty of bugs, that board will be looked at and new features will be forgotten. If you have only seldom bugs, then the bug board will be ignored as it usually won't have any work on it.

A better strategy is to use a single board with a properly prioritized backlog/To Do column. If bugs are more important than new features, then they should be placed on top of the backlog as soon as they are reported. That alone should already give you an insight in how much bug-related work there is. To support this, Jira has different kinds of tickets with different icons.
For developers, they should just pick the top idem of the backlog when they need to pick up some new work. This can then be either a new feature or a bug.

One big advantage with a single board (and thus a single backlog) is that you can easily override the default that bugs have the highest priority and, for example, put a very important new feature above a very minor bug that there is a small typo in a screen (for example, that the login screen contains "pasword" instead of "password"). This will be much harder to realize with separate boards.


Some may argue that the bugs and features should be added to the same board

I would be one of those that argue for one board! Having more than one board will bring problems of synchronisation, clarity and will make prioritisation more difficult.

I'd like a place to see any outstanding bugs and putting them with all the feature requests might make that harder.

Most tools, such as JIRA, allow you to filter your Kanban board to show one or more issue types. As such, you can add a simple 'only show bugs' button that would filter out feature requests and so make it simple to see a bug-only view when needed.


I have lead a team through this transition. This is an important problem to solve. Since your team is still fairly small I would pick a tool that gives you the most flexibility.

If you were all colocated I would suggest a pencil and paper. Since you are not colocated then Trello is the next best thing. This will give you the ability to figure out and confirm your process before getting too deep in any given tool.

Going from 1 to 2 is much harder than going from 2 to 6. This is why you need to keep flexible and communication free flowing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.