Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'd like to advocate the use of issue-tracking software within an organisation that currently does not use it. But there's one aspect of their situation for which I'm unsure of what to suggest: their projects frequently receive informal verbal feedback or casual comments in meetings or in passing from a wide group of interested parties, and all this information needs to be recorded. Most of these messages are noise, but they're vital to record and share with developers for two reasons:

  1. Good suggestions often come out of this process.
  2. It can be necessary to have evidence of clients' comments when they forget previous instructions or change their mind.

Is this the sort of information that should be stored in an issue-tracking system, or kept apart in a separate solution?

Are there issue-tracking systems that have particularly good support for this sort of unstructured information?

share|improve this question

3 Answers 3

If you are the one receiving the informal information/suggestion, ask the person to send you an email. Apologize in advance and stress that you don't want to forget about such a good idea and that your boss prefers a more formal process before considering anything.

I don't think you need a separate system for tracking, but requests should be identified. Not sure there is a difference between a critical feature that doesn't exist and a critical feature with an existing bug. Theoretically, the bug should be easier/quicker to address, but not always. Sometimes there is extra pressure on bugs because it is basically a feature you've made an agreement to include but failed to keep up your end of the deal.

Good issue trackers should be able to handle suggestions and accept input via email. Users like email. Especially when you fix their problem and their inbox pops up with your response.

share|improve this answer

We have two methods of implementing this. One, we have a forum where our resellers and or distributers can post common requests or issues. Two, we keep track of feature requests and inquiries in our bug tracking software (fogbuzz). Support and QA have access to this. We keep this separable for obvious reasons.

share|improve this answer
    
I should have specified that I'm referring to verbal feedback in meetings, etc. not electronically submitted requests. Sorry for the ambiguity. I've edited the question to clarify. –  Ian Mackinnon Jan 29 '11 at 19:23
    
It doesn't really make a difference where the request came from. Our support team fields requests verbally all the time. Then they add them to the system. Our QA team is charge of our betas. They essentially do the same thing. Collect customer feedback...log interesting requests or issues. I am not sure why you think the medium of the request makes any difference. –  Pemdas Jan 29 '11 at 22:40

I think you should separate feature requests / comments from your bug / feature tracking system.

Here how I do it:

I use a system like uservoice.com. It's simple to use for both your users and yourself.

Periodically, I consult them and update the product backlog accordingly.

When we plan an iteration, we add features and/or bugs in our bug / feature tracking system.

share|improve this answer
    
I've updated the question to specify that it's verbal feedback we need to record (sorry for the ambiguity). That noted, would such a system work with a member of the team adding clients' comments on their behalf? –  Ian Mackinnon Jan 29 '11 at 19:28
    
I take notes and update the backlog myself. I use GTD for that with a specific inbox and item processing. –  user2567 Jan 29 '11 at 19:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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