Most issue trackers are targeted towards developers. But when working in a small team that includes business people: does it makes sense for them to put non-dev issues inside the tracker?

I must say I have never heard of that combination. In my full-time job the business things are done somewhere else. But in a startup where you have limited cash, why not put business todos and dev todos in the same tracker?

  • I've seen it done before. Most tools are generally targeted more towards non-devs or devs, rather than both, but as long as the tool itself has the means of filtering appropriately such that people can see all they need to see, and aren't seeing things that don't matter them, it can work out fine.
    – Servy
    Jun 17, 2013 at 20:38
  • As soon as you have the proper permissions it is a very good idea. I have seen it too
    – py_script
    Jun 17, 2013 at 20:42
  • Really, in what kind of environment have you seen that? Corporate or rather startup? I guess the visibility can probably be quite an issue, when some people should better not see certain business things.
    – Philip
    Jun 17, 2013 at 20:44
  • 4
    Some trackers have multiple workflows configurable - that a bug goes through one process, while a feature goes through another. Configuring it so that the proper workflow exists for each type of problem encountered shouldn't preclude business and tech both using it.
    – user40980
    Jun 17, 2013 at 20:51
  • MichaelT: Great idea. We're using Pivotal, I guess we would then create a separate Pivotal project for that.
    – Philip
    Jun 17, 2013 at 20:53

3 Answers 3


To me, as long as there are appropriate filters and queues (so developers are not overwhelmed with tickets about "call Bob about new contract") combining them makes sense.

In my line of work (financial software for external clients), most of the dev issues will require prioritisation from the business anyway. At the end-of-the-day, they are all issues with the client relationship (does the software do what the client wants or is there a bug? have we found an issue in the code which will make the code less maintainable and affect our ability to keep clients happy in future? does client need a new contract?)

The combined approach may also help find non-technical solutions to technical bugs


why not. Redmine (for example) comes with 3 trackers out of the box and allows you to create more. The 3 are bug, feature and support.

bug is obvious, but is feature request a developer thing, or more a design/management issue? What of support - it might not be a bug but a configuration issue.

You can easily add Requirement to the list.

The benefit of adding all these to the same tracker tool is that you can then link them together. Imagine someone creates a feature request that goes through several modificatons through discussion with architects or designers. When management decides to implement this, it can be associated with a 'work' tracker item for you to check your source against, and then associate it with a 'test' tracker as it goes through QA, and then can be associated with support or bug items in the future.

This is called 'traceability' and is huge thing with large scale or very controlled software projects. As long as you don't add onerous workflows to it (ie only a team lead can create a work item, etc) then its a very good thing.


I would keep a tracker to maintain issues raised by business users. This is especially useful when doing requirement gathering. You might want to use the same tracker when you do user acceptance testing to tick-off existing issues or gather feedback from users. I have mostly used multiple excel sheets in same workgroup to maintain various issues(dev issues in one sheet, business issues in another).

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.