1 Replies - 2032 Views - Last Post: 23 December 2012 - 11:07 AM

#1 RudiVisser   User is offline

  • .. does not guess solutions
  • member icon

Reputation: 1010
  • View blog
  • Posts: 3,566
  • Joined: 05-June 09

Tracking Software Separation of Issues / Tasks

Posted 23 December 2012 - 10:16 AM

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 Bug, Feature, 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 Issue.

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 Tasks.

The reason for my question here is that I am wondering if you would see a clear benefit to this separation of process, especially if you are working in larger teams.

Note: I'm asking here for the perspective of developers.. If you're currently managing a team / project from a PM perspective this is cross-posted on Project Management Stack Exchange.

This post has been edited by RudiVisser: 23 December 2012 - 10:17 AM

Is This A Good Question/Topic? 0
  • +

Replies To: Tracking Software Separation of Issues / Tasks

#2 Martyr2   User is offline

  • Programming Theoretician
  • member icon

Reputation: 5543
  • View blog
  • Posts: 14,547
  • Joined: 18-April 07

Re: Tracking Software Separation of Issues / Tasks

Posted 23 December 2012 - 11:07 AM

I can't say I see a real need for change in terminology myself. Usually the fact that an issue gets assigned to you turns it into a task. You have issues dumped into the general pool, the manager comes along, evaluates and assigns the issue to you as a developer. Thus issues assigned to you are seen as your tasks.

I see where you are going with this, I am just not sure if it has to be spelled out. When I login to such systems and I see a list of assigned issues to me, I can focus on only those as my tasks.

Ideally if the manager was good the only issues I would receive as a developer are ones I can act on, do involve work and are suited to my expertise. For instance if someone is requiring a new feature and the manager doesn't want to implement it now, he assigns it to no programmers. Thus if I see such a feature request come in as an issue assigned to me, I would assume it is a feature I am to now implement.

It doesn't always happen that way, but that is how it should work. :)
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1