3

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? Can issue-tracking system have good support for this sort of unstructured information?

Improve this question

4 Answers 4

Reset to default
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.

Improve this answer
0

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.

Improve this answer
2
  • 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, 2011 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, 2011 at 22:40
0

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.

Improve this answer
2
  • 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, 2011 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, 2011 at 19:32
0

Why not. As long as you can record the difference between 'feature requests' and 'bugs' (many times they're the same thing) then I don;t seem any problems with doing so.

Redmine, for example, comes out of the box with tracker types for bugs and features.

Your main issue is keeping a ticket updated with any conversation around the feature request - if there is extended discussion by people without access to the tracker itself, then you'll have to find a way to feed that into the ticket (either give them access, I know systems that can add notes to a ticket by email) or get an internal owner for each ticket to update it accordingly.

I've seen bugs that go on with extended discussion whether it is a bug or 'working by design', bugs where no-one quite knows what the problems is, and bugs where no-one can agree what kind of fix to put in. These are not particularly any different from your feature request.

As an extra, putting feature requests in the same ticket tracker means you can track the changes - from vague feature request to a set of design requirements to work instructions, to bugs rising from the implementation. That level of traceability is priceless.

Improve this answer

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.