Incidents versus Tasks; why even bother using Incidents?

Monday, August 25, 2014
An "Incident" -- which can be of type Bug, Issue, Risk, etc --  does not seem to be anything more than a thing that must be acted upon.   "A thing that must be acted upon" is essentially a task.

So, why even bother using "Incidents" in SpiraTeam?  

One problem with using Incidents is that it is just an additional bucket of data that confuses people and can be lost.  For example, a Release has separate tabs for Incidents versus Requirements & Tasks.  The fact that people have to look at both tabs to get a full picture of a Release is confusing to our users.  I don't personally see any reason why we should just use Tasks alone and not use Incidents.  And, then use separate types for Tasks as needed.  So, if you want to have Issues, Risks, and Bugs, etc., then those would just be different types of Tasks.

Thoughts?  Why might we miss out on if we don't use Incidents and only use Tasks?
1 Replies
Monday, August 25, 2014
re: jfreed Monday, August 25, 2014
Hi Jon

There is a big difference between the two:
  • Tasks - these are preplanned items and are designed to be sub-elements of an overarching requirement / feature / user story. So if a new piece of functionality is to do XYZ, the Tasks will describe the development activities for implementing this requirement in Release 1.1 (for example).
  • Incidents - these are meant to be used for unexpected issues / bugs that have appeared in the functionality and need to be fixed.

The Planning Board in v4.2 has been rewritten to make this clearer, with Tasks being seen as elements of a requirement being planned, whereas Incidents being items of their own that need to get planned into the scope  of work.



Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885


  • Started: Monday, August 25, 2014
  • Last Reply: Monday, August 25, 2014
  • Replies: 1
  • Views: 12659