Is there a clear benefit to separating "issues" from "tasks" when working in larger teams?

Question

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

Answer 1

Before going into a system that offers the segregation between a task and an issue, would like to make sure the users are very comfortable with the terminology and, more specifically, when using one or another.

As you pointed, systems usually use the same nomenclature for identifying something outstanding. I believe that's mostly because users don't care how IT will call it. So, as long as the system's users clearly know when identifying something as a task or an issue, you'll have trouble further down the road.

Another possible scenario is that tickets will be mostly submitted by persons who clearly know the difference. In this case, why not using a piece of information to differentiate tickets? In our case, we agreed that when the field "due date" is populated, it means that's a task that's going into prod, to segregate to other tickets not prioritized yet.

Maybe, the efforts to change the system in place to another that offers the segregation between task and issues may not pay off. Bear in mind thattthere's always the learning curve for any new systems and if you have your client entering tickets, may not be nice to burden them into a new system "just to make things easy to IT".

In your case, you could pick any field your team isn't very used to use and agree that that field will be the "task identifier" (a field that can only be seen by the IT preferably).

Back to the system question : jira could fulfill your need. But keep in your mind that such differentiation is more cultural than systematic.

Answer 2

I think we're trying to solve the same problem, that being the challenge of prioritizing different types of work by categorizing at the entry phase or at least very soon after entry.

I've worked with systems that have had a single issue type ("bug") to a current Jira implementation with three ("deliverable", "task" and "bug"). The one-type system resulted in lots of weird labels and documenting standards to distinguish "bugs" (unplanned work except in the general sense) and "planned work". The three issue-type system has evolved over five years and suits my organization's needs.

Deliverable: Formal project work, it's estimated, detailed, has completion tests and a formal review/acceptance step. Typically rolls up to some kind of contractual obligation.

Task: Less formal, no review step. Basically "to do" items often entered by developers themselves. Exists due to a desire to capture otherwise unknown work in the form of notepad lists, outlook tasks, etc.

Bug: Typically entered by QA testers. Reviewed (we call it triage) and prioritized for action relative to it's severity. A severe bug may take precedence over a deliverable, a very minor bug could wait in the backlog for a long time. A bug fix is verified by the reporter.

Note that both deliverables and bugs have review/verification steps. The difference between a deliverable and a bug is that deliverables aren't broken yet.

Answer 3

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

What you're referring to here is a state change not a separate item. You need a way to capture the initial state of the item as an issue, and then a way to change that state to indicate that it has been viewed and approved by the PM's and is ready (or has been) scheduled.

In TFS this is simple, when new base type work items (name varies depending on template) the state is something like "proposed" or "pending". Once it has been approved the state is changed to "approved".

This method ensures transparent reporting and also that work items don't get lost. If you used two completely separate work items you could easily run into issues where the item failed to migrate properly. Each state has it's own method of closing, so a work item that hasn't been approved could be rejected, but a work item that has been approved can be completed or canceled.

Answer 4

I think this is a great question, and I appreciate the detailed context. I agree with @aclear16 that this more a state change than two separate trackable entities. I think what you're really dealing with is fundamental change control.

You've defined "Issue" as some input from a third party that indicates a desire for change. Logically that change request should be analyzed to discover what impact it has on scope/schedule/cost/quality/etc. Based on that analysis the PM develops a work package to address the issue - what you're calling a "Task".

Tasks should be submitted to the relevant stakeholders (change control board) for prioritization and resourcing. (sometimes the CCB does validation and a separate entity does prioritization and resourcing). At that point the schedule is changed to include the task.

Answer 5

TL;DR

Don't conflate project inputs with commitments for deliverables. This appears to be the underlying X/Y problem that's being addressed by the question.

The Problem

Traditionally, all issues are entered into a tracking system as exactly that - an "Issue".

The problem, as I see it, is that your tools dictate work-flow, and you are trying to differentiate between uncontrolled process input (issues) and controlled, ordered process deliverables (tasks).

To the extent that you've already defined a distinction between the two, there's no actual problem. The problem, as such, is that you haven't modified your work-flow accordingly, and that to some extent you're constraining your work-flow based on your existing tool-chain.

There also seems to be a missing process step. Specifically, the process where issues are triaged and assigned, prioritized, and scheduled---or not, as the organization's needs dictate.

Potential Solutions

There's no inherent value in differentiating between "issues" and "tasks." What you really need to do is fix your process to differentiate between "stuff we want to spend time and money on" and "stuff we don't care about."

To that end, you need to review your triage process, or create one if it doesn't exist. Someone should be reviewing issues as they come in, assessing the business impact (if any), and identifying it as a deliverable if it merits the effort and resources.

In Scrum, this would be the job of the Product Owner. The PO prioritizes the Product Backlog by identifying business value, and places the job on the backlog in a slot determined by both intrinsic importance and the dependencies of other backlog items.

Leverage Your Bug-Tracking System

If you insist on remaining constrained by your current tool-chain, you still have a couple of options.

1. Use a different bucket for work that has not been triaged.

   This is essentially a slop pile, from which the Product Owner (or equivalent) can select work to be transferred to another bucket from which work is actually assigned. Except for triage, no work is performed directly from the untriaged input bucket.

2. Use the same bucket, but only work on triaged and appropriately-labeled issues.

   Most bug-tracking systems allow labels, prioritizing, and scheduling. If your bug-tracking system is really your project's deliverables bucket, then make sure your triage process labels work to ignore as "wontfix" or similar, or assigns severity levels, due dates, and milestones to the work that should be performed.

Either way, the solution is ultimately the same: Stop treating issues or bug requests as a commitment for specific deliverables. Regardless of the format or nomenclature, your issues system is simply providing input to your process. It's up to the organization to assess value, and the responsibility of the project team to estimate effort and commit to specific tasks and milestones.

Answer 6

A task is the execution on a work package. It flows from a premeditated project planning activity (whether that be a user story or waterfall type project plan). A task is a planned activity.

An issue is a bug, risk or challenge that comes up during the execution. It flows from the work in progress. An issue is an unplanned activity.

Whether an issue becomes a task is subject to your change control and/or risk management process. This process is where you decide when a bug becomes a task or whether a positive risk (an opportunity), for example, becomes a feature. From there you would flow it back down to a planned activity (like building the feature or addressing the risk).

If the bug comes up during testing/QA, i.e. during the development of the product, you have to decide when the software is "done" and off of that, base decisions for bug fixing.