The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem Records vs Defect Records - When and how use which/when

jamesmcwhinney
Mega Guru

We are trying to use the Agile / SDLC module to track our development work against the platform, creating enhancement records and defect records, then creating stories and linking them to a release.

The process is pretty rough around the edges, but it is working for the most part.

Our current process is:

1. Incident received from end user.   Dev team troubleshoots and provides a workaround if possible.   Dev team creates an enhancement or defect record which is then reviewed at the next weekly meeting.

2. enhancement or defect record is approved or denied, and the end user is notified via their incident that the enhancement or defect has been added to the product backlog.   Their incident is then resolved (even though they may still be experiencing the issue or have a need for the requirement).

3. Stories are created for the approved enhancements or defects and are ranked / prioritized.

4. High priority stories are added to the next release and developed.

5. We manually track the relationships between the incidents and the approved enhancements or approved defect-fixes, and notify the end user when a release date is confirmed for their enhancement or defect-fix.

This works,. but I am curious of a few things:

1. We will want to introduce problem management soon.   How do problem records fit in with defect records???

2. What is the best way to give the user visibility into the problem or defect?   Should we add the user to the watch list for the problem or defect and then close out their incident?

What makes the most sense?

Id be grateful to hear anyones thoughts on the topic.

Thanks in advance!

- James

3 REPLIES 3

Sashi K1
Kilo Guru

Hi James, good questions. These are related to process. Let me see if I could provide some insight on Problem/Incident/Defect.



By definition Incident is something broken in the production as a result of


1. Testing gap


2. Code defects


3. Missed requirements



All above three explains when an Incident gets created. If a newly deployed app not tested or code properly and requirement very much clarifies what is expected then its a 'Defect'. If the requirements were not captured completely then an Incident happens then its an Enhancement. Unless its operational issue (like internet went down causing a Website to unavailable, network issues), most of Incidents ends up either by a Defect or an Enhancement.



if Defect you would assess business impact. If high, you would perform an emergency change as long as requirements clear on what is expected. If requirements didn't capture a case then its an Enhancement. You would again take route based on business impact and urgency.



Problem is an reoccurring of an Incident (in this Incident world). Say for example, if an Incident created against a network issue due to router down, it will be resolved by keeping the router up. If you see this is reoccurring then you would need an RCA to find root cause of reoccurring Incidents. You create a problem record of unknown cause, make a resource to work to analyze whats causing an Incident to reoccur. Also true in the case of multiple Incidents created across multiple CI's as a result of parent CI down. You would perform RCA on mass impact of dependent CIs. In all these cases a Problem is something you would need an investigation on a root cause of a major failure or a repetitive issues. Where you need an investigation or a root cause to define. Most of Problems ends up creating a Change request to address a reoccurring problem. In above example change routers or upgrade products etc.



Incident will have all these related records, either a Defect or a Enhancement when requirements broken or miss-captured.


You see a problem when a reoccurring issue or a major impact happened multiple CIs resulting multiple Incidents. In this case Problem is to identify RCA for he major damage.



In the both the cases you would see a Change either normal or emergency depends on business impact and urgency.



Hope I provided some light around them



Thanks


jamesmcwhinney
Mega Guru

Here is another post I found here:


Re: Incident and SDLC Intergation



Mike Kohlbeck wrote:


Defects


For defect handling, users should report a production issue with their service as an Incident. Incident allows for relating of multiple incidents and the creation of a related problem to determine root cause. It is not always clear if an incident is an application defect so that is the purpose for problem management. Incident would stay focused on resolving the issue with the service as quickly as possible by applying a workaround if available. In addition, problem management can assess related incidents to determine the priority of the problem if you are relating incidents to the problem. In problem, once you determine the problem root cause is an application defect you can set the problem as a known error. Then consider creating a defect in SDLC that can be prioritized for a future release. You can also create a related change to the release and problems it is fixing. After the defect is fixed in a future release and you validate the fix make sure to close the problem and related incidents.


Enhancements


Best solution is to use ServiceNow Demand Mgmt for intake of enhancements requests which allows you to vet the request and determine if it should be rejected or become an enhancement, defect, or project, which can be handled in SDLC or PPM. If you don't have Demand Mgmt then consider a request with workflow or manual process.




This seems to suggest that for production related issues, it would potentially be incident->problem->defect...


That seems like alot of records to maintain,..


Which one does the user subscribe to?   Does the incident typically stay open until the root cause is fixed? or only until a workaround can be provided?


This is a custom process whether to keep an Incident or close it when RCA is ready. Normally when an RCA is initiated, Incident priority changes and status is to 'waiting for other' until a root cause is identified. Once an RCA is found, Incident could be closed and add user to the Problem record awaiting for a Change. This is what ServiceNow follows. Once an Incident is waiting on a Problem they would recommend to close the Incident as there is anything much pending on Incident. ServiceNow creates/updates existing problem record to our company (or User in our case). At this point they propose to close that Incident. Which is right way of doing.



But same ServiceNow keeps the Incident with low priority with 'awaiting other' status, if customer insists to keep Incident open until Problem is addressed in a future change. That way customer notified when Incident status changes. In this case they keep it open.



So above is a custom process. With my experience, we always closes the Incident when there is nothing to be carried out on that Incident, while making User to hear updates from a Problem record.