I'm curious how other development teams (especially those that work in moderate to large development groups) track "future" features/wishlists for functionality for internally developed frameworks or components.

I know the standard advice is that a development team should find one good tool for tracking bugs/features and use that for everything and I agree with that if the future requests are for the product itself.

In my company we have an engineering department, which is broken up into multiple groups and within each there can be one to several agile teams. The bug tracking product we use has been "a leader since 1997" (their UI/usability seems to also be evaluated against that year even today) but my agile team or even group doesn't really control what is being used by the whole department.

What we are looking to track is not necessarily product features but expansion/nice to have functionality for internal components that go into our product. So to name a few for example...

  • framework/utility library on top of CppUnit which our developers share
  • low-level IPC communications framework
  • Common development SDK that myself and several other team leads started to help share some common code/tools at the department-wide level (this SDK is released as internal "product" to each of the groups).

Is the standard practice to use the one bug tracking tool? Or would it make more sense to setup something more localized specifically for our needs and maintain it ourselves? It's also unclear how management will feel if developers start performing "IT" roles of maintaining software and servers.

At the same time, right now, we use excel files, internal wiki and MS OneNote for this kind of stuff and that just doesn't feel right.

(I'm afraid to ask for actual software recommendations, since that might make this question more localized or something. Also developers needs this way more than management, so it would be nice to find something either free or no more than the cost of a happy hour).

1 Answer 1


With regards to how management might feel about setting up something localized, I think that the most obvious answer is to simply meet with management and asked outright for their opinion on the matter. Better yet, have a couple of ideas to introduce and see if you can encourage your managers to take those ideas on board.

A tool is a tool. It's only as good as the person using it. If something doesn't feel correct, ask yourself what aspects of the presently used tools are the things that cause you to feel this way, and then look at your options. You might customise, improve, or replace depending on how you and your colleagues feel about it. Also, you need to have the entire team buy into the idea. If everyone else likes the system already in place, then you might be fighting a losing battle. On the other hand, you'll probably find that many of the issues you raise with regards to your present tracking system will probably be seen by your colleagues as problems and they just might have some good ideas of their own to share.

As for what to use, any good issue tracking system could be customised to the purpose you wish. For example (forgive the plug), we use a Redmine system (yes, it's free as in gratis) where we work, and we have set up a kind of meta-project that we use as a kind of dumping ground for ideas and requests that don't seem to fit well within any existing project. Every few months, we go through the list, remove items that are no longer relevant, and expand on ideas that require more discussion. The nice thing for us is that Redmine allows us to create new projects that we can link back to the original feature/issue in our "dumping ground", and we can easily move these offline issues to other projects as necessary. We find this works for us, and we have tuned the tool to suit our purposes in this regard. What I'm getting at is that with a little lateral thinking, you may find that your existing issue tracking system might be able to be tuned to suit your needs in this regard. The benefit of this is that management will be happy that you didn't spend any real money, and your IT department won't have to worry that you are trying to do them out of a job! ;-)

  • so far this is definitely the best answer.
    – DXM
    Commented Nov 15, 2011 at 8:06

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.