Question which is bothering me for some time is whether you should have one tool for bug tracking and another one for feature/story planning? Or should you keep bugs and features in one system.
I think the root cause of this issue lies in misunderstanding of ”bug” and “feature” concepts. End users and software developers look at the same things from so different angles that it is almost impossible to have common view. Old popular comics below illustrates this issue pretty well.
Bug vs Feature
Lets first take a look from end user point of view. There should always be the way for user to register his ideas or issues with using the developed system. So what you do, you give him/her access to your issue tracking. If you are running software product company this could be customer forum or community site like GetSatisfaction or UserVoice, where users shout their opinions without risk to be punished.
So far so good. Now software developer gets into the same system and the fight begins. Argues, whether this issue is a bug or feature, is taking off. Users start pushing to put bug fixes into current iteration, developers fight back by calling issues the features and asking to leave those out of the scope. I guess it sounds familiar.
That is why I think it is healthy to keep bug/issue tracking separate from your project planning. Also you can call me psycho, but emotional aspect is very important here. My point: don’t hold dreams (read: features requests) together with problems (read: bugs). When you do release planning it kills the whole motivation of the team when you see that there are 5 times more bugs than new features planned. We, development teams, like to do something new and not just fix the bugs.
Key goal of bug tracking system is to communicate with customer, understand his point of view, document the issue as much as it is needed and then pass it over to development team. Development team can treat this issue in the plan as new functionality. Call it feature, if it makes you happy. It doesn’t matter.
There are also different styles of using bug and task tracking depending on your company/project time. Software product companies that don’t have direct contact with end user can live with one system with no problem.Though, if you are a service provider and all of your project are done for external customers separate bug tracking is almost the must. From my experience in different types of software projects, I like having separate bug tracking anyway. It makes person responsible for tracking bugs to think like a customer, even you don’t have one participating in the project.
I am an enterpreneur, currently the co-founder and CEO of Programeter.com, a business intelligence company targeting software development managers. In this blog I will share my opinions and interesting finding on topic of tools for software development teams.
Great article, Mark. Jeff Atwood in his blog “Coding Horror” has written on similar matter, and his blog post “That’s Not a Bug, It’s a Feature Request” gives additional points to your motives towards separation of tasks and bugs tools. You can find his post here:
http://www.codinghorror.com/blog/archives/001189.html
At our web design & development agency we keep them together. The main reason being that we handle web site updates using scheduled milestones. When we launch an update, some of the items going up are bug fixes and the rest are features. Makes it easier to manage if they are both in one place.
Another reason I see to keep them separated is that they shouldn’t even use the same tool! Or at least, they shouldn’t use the same form for submitting entries. Most of the time, developers need much more information than an end-user can provide. Things like version involved or system configuration should never be seen by the end-user. Try asking end-users to file bugs in JIRA, and either they won’t do it, or you will end up with plenty of dummy entries.
The ideal would be a tool that allows an end user to file bugs with as few structured information as possible, then someone could review those “complaints” and discuss with the user to have more information or just explain to him/her what (s)he is doing wrong. And if it happens to be a real bug, or a good feature request, the system should make it as easy as possible to transform it into a developer-targeted issue with more information for internal use, while keeping a link to the original constraint so that the end-user gets notified when his/her complaint has been resolved. What do you think?