Is there a clear benefit to separating issue from task when working in larger teams?
When working with sizable teams of developers in addition to a number of external clients, QA, and any other form of testers for the development of a software application, it's only logical that an accessible issue tracking system is used.
Traditionally, all issues are entered into a tracking system as exactly that - an "Issue". These "Issues" would then be divided primarily by a
Type field on the issue which defines whether it is a
Task or otherwise. Generally, the terminology used for this is defined by the tracking system that is being used and so couldn't be changed for example from "Issue" to "Task".
This leaves developers, project managers, external users and QA all working from the same queue of "Issues", with all of them entering into the same queue only separating by a field on this issue.
What I am trying to envisage here is a system that separates between the concept of an "Issue" and a "Task" on a core level. That is, to redefine the usage of these terms in Project Management Software.
Issue - An unscheduled article / question / comment relating to a project that was entered via a third party, be it a tester from QA or a client experiencing an issue.
Task - A verified item that has been scheduled by the Project Manager or simply taken on by a developer. This can be seen as a
Work Item that is to have work performed on it. It may or may not be a verified
The idea is that most third-party queries/requests would be entered as an
Issue, and then migrated into a
Task and subsequently scheduled and assigned by the Project Manager before work is completed. This will allow for clear separation of assignments, developers are able to stick purely to a
Task queue to be able to find and complete their work, and Project Managers / support assistants (as an example) are able to use the
Issue queue to be able to clarify issues fully before converting them to committed