How Defect and Enhancements (agile development) are actually designed to work?

Suggy · 5 hours ago

1. How Defect and Enhancements (agile development) are actually designed to work? like its lifecycle?

2. Is it something which can be exposed to end users or it shouldn't? as a best practice

3. Incident vs Defect? which one to use and when? any criteria around it?

Especially regarding point 3, we had a discussion for an hour. What happened is, we deployed new record producers (created via stories) to PROD. User found some wrong variable mapping.

Now should an incident be created or Defect?

NavinAgarwal · 4 hours ago

Hi @Suggy ,

In an Agile ServiceNow environment, both enhancements and defects go through a similar lifecycle, moving from an initial state through a process of scoping, designing, developing, and testing before being deployed. Enhancements are new features, while defects are existing issues, both of which can be linked to "Stories" in a product backlog. The process is iterative, with records able to move back to earlier states if issues arise, and it culminates in the record being closed upon successful implementation.

The lifecycle:

Draft: The initial creation of the enhancement or defect record.
Scoping: Gathering business and functional requirements to define the work needed.
Designing: Creating the technical specifications for the solution.
Development in Progress: The coding and unit testing phase, which can include peer review.
Testing/QA: Acceptance testing is performed by the QA team or stakeholders.
Awaiting Change Approval: For higher-priority items or those outside the standard release cycle, a Change Request is submitted and waits for approval, often from a CAB (Change Advisory Board).
Change Approved: The Change Request has received approval and the change is ready for deployment.
Deploy/Launch: The change is released to the production environment.
Closed Complete: The enhancement or defect is fully implemented and verified.
Cancelled: The record is no longer being pursued at any point in the lifecycle.

Key interactions and considerations:

Agile Development application:
You can create a Story from a defect or link a defect to a story in the product backlog.
Iterative nature:
The process is cyclical. If issues are found during testing, the record can be sent back to the "Development in Progress" state.
Prioritization:
The lifecycle is driven by the priority and required response time for the enhancement or defect.
Change Management:
A formal Change Request is often required for deployment, especially for high-priority items.
Closing:
If the fix or enhancement is not accepted during validation, the record can be returned to the developer for further work with the product owner.

For Point#3:
You should create a defect (or a bug) for a wrong variable mapping, not an incident. The key distinction is that a defect is a deviation from requirements or a flaw in code, while an incident is an unplanned interruption of a service. Since the new record producers are not working as expected due to a coding/configuration error, a defect is the correct category.

Criteria for creating a defect vs. an incident:
Defect:
A flaw or error in the code or configuration that causes a deviation from the expected functionality or requirements.
When to use: When a user or tester finds a specific issue with how the software is working, such as a broken button, incorrect data display, or in your case, a wrong variable mapping.
Example: A user reports that when they submit a form, a field is saving the wrong information. This is a defect because it's a deviation from the intended functionality.
Incident:
An unplanned interruption to an IT service or a reduction in its quality.
When to use: When a system is completely down, a service is unavailable, or there is a broader performance issue affecting multiple users.
Example: A server crashes, making the entire application inaccessible to all users. This is an incident.

Your specific scenario:
In your situation, the users found a "wrong variable mapping" in the new record producers. This is a specific, identifiable problem with the software's implementation.
It is a defect:
Because the mapping is incorrect, the functionality is not meeting its requirement. It's a flaw in the code or configuration, not an unplanned outage.

It is not an incident:

Unless the incorrect mapping is causing the entire application or a major feature to be unavailable, it should be treated as a defect and not an incident.

If you found my response helpful, could you please mark it as ‘Accept as Solution’ and ‘Helpful’? This small action goes a long way in helping other community members find the right answers more easily and supports the community.

Suggy · 3 hours ago

Sorry, I dont want an answer from Copilot. I have already seen above response from it. It still doesnt answer my question.

NavinAgarwal · 3 hours ago

Please help me understand which part of the question isn't answered, I would try to answer in the best possible way. I will always go for a defect for your scenario as it's a bug in the system even if it's identified by the end user. You can always create an incident for user tracking and defect for solving the bug. We never use Incidents for bug fixing. Incidents should be used to restore service quickly while the underlying bug is logged as a separate task in a development backlog like a Jira issue or a ServiceNow "Problem" record. This is because incidents focus on immediate service restoration, while bug fixes require a separate, deeper process for analysis, development, and release management to address the root cause and prevent recurrence.

Please note Copilot is used to frame the answer how I wanted to answer rather than typing everything on my own. It's ok if it didn't help you. Thank you!

Doug Page · 3 hours ago

Have you considered using Collaborative Work Management for this process? With Connected Work, you can now bring in work from the across the ServiceNow platform into CWM and manage in Kanban or Scrum.

https://www.servicenow.com/docs/bundle/zurich-it-business-management/page/product/collab-work-mgmt/c...

Doug