Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Defect versus Incident - what is the difference and why does it matter? | jimiwikman.se

    Defect versus Incident - what is the difference and why does it matter?

    Posted , 1,101 views, 0 comments

    Some people say Defect and some say Incident. Both are correct, but what is the difference and why does it matter? In this article I will explain how I see the difference, why it matters and perhaps more importantly when it matters. 

    When it comes to defects, then we have already defined that a defect is when the solution does not fit the requirement. We also defined what a defect is not, so we should be fine with just the term defect. Right? Well, there are actually a few reasons why we should actually have have two different definitions for a defect.

    The Legal Aspect

    One of the least understood aspect of defects is the fact that there is a point in the development process that change the way we manage defects. That point is when a solution is accepted, which occur during the acceptance phase before code is deployed and released in production. From a legal perspective this is when the standard agreement between the client and the provider is fulfilled.

    There might be additional services added beside the standard agreement that add another layer on top of the standard one, like a post go live support period or extended defect management after release.

    This point in the development is also where responsibilities sometimes shift from the development team to a maintenance team for example.

    The Complexity Aspect

    Another important aspect is the complexity aspect that comes into play as the deploy is released into a production system. Even if the pre-prod environment is identical to the production environment it is still withing the development teams responsibility. Once put into production this usually changes and the complexity with the full solution as well as the full network make it a much more costly affair to manage problems.

    When issues occur in the development teams environments it rarely involve other teams. Problem are managed within the team with the occasional support from surrounding system teams or network teams. Once you go to production however problems often become the affair of many teams.

    The Workflow Aspect

    How the team work with a defect is not the same for something found in a production environment, for obvious reasons. In a normal development workflow you can choose what code go to production, but for a defect found in production you do not have that choice. This is why you bypass the normal workflow and use hotfix, which is a fast track to correct problems in production environments.

    Two ways of working, two types of defects

    Based on the fact that we do have different processes for a defect found in production and for a defect found in the lower environments we should separate the issues themselves. This is not just to make it easier to identify in for example Jira, but also since there can be differences in who will manage the defect and the process to manage the defect itself. It also allow us to define the defects differently.

    Defects are problems that prevent acceptance.

    If there is a defect, then acceptance should not be given. It is a problem that only affect the legal aspects of an agreement. It can cause delays, which in turn can damage the company financially, but it will not affect the end user as it has never been released. By definition a defect is considered an internal problem and solving it involve only the development team within the standard way of workflow. It is simply development not yet complete.

    The severity of a defect determine when in time it should be fixed based on dependencies withing the project as well as surrounding systems.

    Defects are considered free since they are part of the development agreement.

    In Jira a defect is placed inside a development to block it from going into production.

    Incidents are problems that can damage the company.

    An incident found in production is available to end user and as such it can cause damage to the company. It can cause disruption of service, it can damage the brand perception or even cause direct impact on sales. Solving this problem often involve multiple teams and it require a separate workflow that disrupt the standard workflow.  By definition this is an external problem and it can cause legal issues as it is found after acceptance has been given.

    The severity of the incident determine when in time it should be fixed based on the damage it causes.

    Incidents always comes with a cost, which usually is some form of support or maintenance agreement.

    In Jira an incident is a standalone issue that is handled as development task.

    incident versus defect.png


    This is my way of defining the differences between a defect and an incident. I have found that by making this distinction I can design better workflows in Jira that make incidents more visible. I can also use this in Jira Service Desk and other systems and by separating the two types I am not limiting the different workflows and I do not have to bloat the workflow by combining the two into one.

    Do you agree with my definition?

    User Feedback

    Recommended Comments

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Similar Content

    • By Jimi Wikman
      Jira tool manager with the task of stabilizing the system and setting up work processes for all teams within H&M. Responsible for several projects including cloud initiatives and coordination with other systems such as ServiceNow. Heavily involved in designing the build processes (requirements, development, design, deploy and test) for the process office. Responsible for the design and implementation of SAFe in Jira and the build processes. Responsible for a small team of Atlassian experts. Supported 400+ teams with Jira questions and training of work processes.
    • By jan.ogren
      I have a long experience in business analysis, agile methods and project management and a genuine interest for the digital customer journey. The last 11 years I have focused on e-commerce within retail.

      I am used to working in complex projects and collaborating and communicating with several stakeholders. I am good at acquiring new knowledge, understanding the business and it´s needs and analysing and prioritizing those needs. I am used to improving processes and coaching scrum teams and organisations in an agile way of working. I am solution-oriented, goal-oriented and flexible. My goal is to continue to develop within BA and agile, so that I in future assignments can contribute in the best way to making sure that what is delivered is prioritized, in line with the business goals and fulfilling the customers' expectations.

      Areas of expertise
      • Business Analysis
      • Agile software development
      • Project Management
      • E-commerce strategy

      What drives me is that each assignment gives me the opportunity to bring about change and optimize. I get to know people and share knowledge and experience. In addition I learn more about the customer's business and digital landscape.

      My latest consultant assignments
      • H&M (Business Analyst)
      • J.Lindeberg (Feasibility study - GDPR)
      • Axfood (Application Expert SAP Hybris Commerce)
      • Axfood (Business Analyst and Scrum Master)
      • Bonniers (Product Owner)
      • Reima (Product Owner)
      • Stadium (Agile Project Manager and Business Analyst)
    • By Jimi Wikman
      Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that.
      I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled.
      When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap.
      Requirements & test management in Jira
      RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like.

      The RTM Requirements module
      This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots.
      You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not.
      While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far.

      The RTM Test Cases Module
      Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses.
      As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots.

      The RTM Test Plans Module
      Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases.
      To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up.

      The RTM Test Executions Module
      The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently.
      There are some things I think can be improved visually, but overall this works pretty well.

      The RTM Defects Module
      The Defects module give you an overview of the defects in the projects.  If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots.

      The Good and The Bad
      There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test.
      Version management
      What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global.
      Acceptance Criteria
      This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing.  This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements.
      Import from other projects
      One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution.
      Quickfilters in Defects module
      The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary.
      The Module Templates
      While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters.
      Better integration with Confluence
      If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to.
      Other Apps support
      Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs.
      Test Executions UX and Visuals
      The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view.
      The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard.
      Colorful folders
      This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set.
      My opinion on RTM from Deviniti
      This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today.
      When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance.
      I like it. A lot.

      View full blog article
    • By Jimi Wikman
      When working with IT projects you can not help but to run into defects and issues in different environments that require fixes. Strangely enough this is often poorly defined and I have seen some creative ways to manage the many different things that is being called defects. So what is a defect really and if something that is not working is not a defect, what is it and how do we handle those?
      Defect. Bug. Incident. You have probably heard all of them mentioned, probably in the same development project even. Maybe you are one of those unfortunate ones that even have something as weird as a "defect type" to define what type of defect you are dealing with? Well, you are not alone. This is a common issue in many organizations and in this article I will describe my point of view on this subject.
      What is a defect, for real?
      This is the ONLY definition of a defect.
      I know a lot of people will object to this because defects can be found that is not described in a functional, or non-functional, requirement. This is true, but you forget that we always have implicit requirements such as that the system should work as intended.  This means that all defects can be tied to a specific requirement, or to an implicit requirement.
      The only issue with this is that for some tests it can be hard to actually connect a defect to a specific requirement. This happens especially with exploratory testing and in large, complex solutions. That is perfectly ok and you should not spend time finding the exact requirement if it does not have a positive impact on the work process itself. We want to improve the quality of the system after all, not build the perfect documentation.
      The different types of defects
      As a Jira expert who design workflows for many organizations I sometimes get asked to add a custom field for labeling defects in different ways. The answer is always no. You can not have different types of defects because it is either something that is not working according to a requirement or it is not. It is as simple as that. Adding labels to defects is just a band-aid for a work processes that does not work.
      Common labels people want to use in these situations are:
      Not a Defect - This one is hilarious to me. If it is not a defect, then just close it and move on. No need to have it open with a label saying it is not a defect. That is just a sign of uncertainty from the team that you do not have the courage to actually close things. System issue - This is a label that again is just stupid. It is still a defect, you are just pointing towards someone else to blame for the mess. Don't add a label, just hand it over to another team. New Requirement - You can not have a defect that is also a new requirement for obvious reasons. If this was timetravel you would just be responsible for creating an endless loop. Close the defect and create a new requirement, or change the defect to a new requirement. Changed Requirement - This is just petty and a bit cowardly because if you are dealing with unclear requirements then you bring that up as a problem and fix it. If you have a proper requirement process, then this will never occur, so just close the defect if someone change the requirement after development starts and add a new development task for it. Don't feed the trolls that are responsible for poor requirement management, squash them and get things working the way they should. Design bug - Design is part of the requirement process. If you have a defect because the design was updated, then see my comment on changed requirement. If you did not follow the design specification, then it's just a defect. Can Not Reproduce - Well, that happens and what you do is that you make sure you have steps to reproduce and that you talk to the reporter. If you can not reproduce despite that, then you just close the defect. Wrong Team - Well, then just reassign the defect to the right team then. This is just lazy... In most cases labels like these are invented because the team do not feel comfortable bringing up that the requirement and test process have issues. Rather than adding labels to passively stick it in the face of the people in charge, I suggest you instead add other types of data to be added to every defect:
      Steps to reproduce - This is a must and it should be detailed so anyone can verify. I usually say that the reporter should ask the janitor or receptionist to verify the steps to reproduce before submitting the defect. If this is not clear, then close the defect with can not reproduce. Eventually people will learn how to write this properly out of sheer frustration. Better yet is to help educate the reporters so they get this right. Environment - Where was this found. All development should be done in 4 environments: Development, Test, Pre-prod and production. All defects should be found in test or pre-prod. Defects found in production are incidents and defects found in development just means that the development is not done yet. Affected Version - Not always applicable, but if you do not have continuous deploys several times a day all the way to production, then you should have a controlled versioning system. Anything deployed to test and pre-prod have a version, even if it is just a tag. So make sure you ask that this is added as it will help you understand what code base the defect is present in. It also make the reporters more inclined to keep track of the code deploys. Connected Requirement - This can help reducing the problem with "nagging" or scope creep. That is when you get defects that have no basis in the requirements, but are usually new requirements. If this is a big issue, then make this mandatory or close defects without this field until the reporters learn what a defect actually is. Component, Module or System - Useful to make sure the right team get the defect if you are in a multi team setup with multiple components or systems. Stop working with poorly defined defects and take control over the process for reporting defects. Crappy defects exist for a reason and while it may be very difficult to speak up in some cases you should always try. Bad defect processes will impact morale and system stability.
      Remember: A defect is when the solution does not match the agreed requirements.
      Nothing more, nothing less.

      View full blog article
    • By Jimi Wikman
      Working on multiple projects at the same time is sadly a common experience for many of us working in IT. Many split their attention on at least 2 projects or responsibility areas. This comes at a cost however, not just for the person splitting their time, but also for the people they work with.
      Few lift an eyebrow at the mention that someone is in a project for as low as 20% these days. Sadly no one really bat an eyelash when a coworker break down mentally and get sick from the mental stress either. In my line of work as an IT consultant I often see people splitting their time and I see what it cost those persons as well as the projects they are doing their best to contribute to.
      Not to long ago I witnessed a co-worker taking a seat after lunch looking pale. A faded smile and assurance that he would join soon and just needed a moment to himself was followed by an ambulance taking him to the hospital. It took him a year to come back to work. More than once have I seen people pass out in a meeting and outbursts of anger and frustration for small things happen on a regular basis by even the most gentle and kind persons.
      What could possibly cause such extreme amounts of stress? The answer is that all of these people have suffered from extreme forms of content switching. As a human we need time to focus in order to make rational decisions. As the time to focus is interrupted we experience content switching. That is that moment when you are forced to go from one focused thought to another. This change of focus comes at a cost of mental energy and eveyone need a different amount of time to make the switch mentally.
      As a manager you do this a lot as part of your work. That mental flexibility and speed that you have as a manager serve you well to manage most situations. That is because the content switching is still within one context. When you need to split your attention on multiple context however the cost will increase exponentially and with time, you will build up negative stress. If you do not reduce that stress it will eventually cause physical harm and you will hit that famous wall head first.
      Other fields in IT have the same situation, but there is one group that suffer from this more than any other group: the developers. Developers unlike most other groups are focused oriented, mening that they spend more time in their own minds setting up structures and logical flows that create the code they write. Once interrupted it takes far longer to get back to their focused state of mind. Fortunately developers are less likely to work on multiple projects at the same time, but when they do the damage is more severe than for other groups. Designers have a similar situation, but have an easier time to make the mental switch.
      How to mitigate and avoid getting burned out
      Speed is everything, or so they make you think. Meeting after meeting where you jump from onte topic to the next in frantic speed. As you solve issue after issue with your quick and skilled mind you will experience a sense of accomplishment. This is because your brain reward you for it and it becomes an addiction. Soon you will crave it and like a junkie you will crave your fix even when you are off work. Eventually the rewards will not measure up with the cost and you will get frustrated and eventually have problem being happy. A sense of feeling empty and caught in a endless loop is your last warning before you bend the knee to the mental exhaustion and collapse.
      The price you pay fror strecthing yourself thin benefit no one as you break down. There are things you can do however to prevent this. Both as regular practices, but also as strategies and rules you set for yourself.
      Managers, Requirements & Business people
      Make time for focused work - As a manager or if you work in the Business area the biggest danger is having long periods without proper focus. Meetings and workshops take up much of your time, so make sure you dedicate at least 1 hour every day for focused work (no, not during lunch...). This is a time where you take time to be fully alone without distractions to focus on emails, power points and whatever else you have promised to do. This will naturally lower your stress levels and allow you a form of soft reboot. If this does not work, then dedicate a longer period 1-2 days a week. This can be that you work from home one day once a week or two half days for example.
        Turn off at the end of the day - The most common mistake managers do is that they never stop working. My suggestion is that you leave the computer at work if you can, or leave it in the bag when you get home. The same goes for the phone. make sure it is turned off as soon as you leave work, or at least as soon as you get home. If you are required to be reached every hour of they day, then you are constantly on stand by and never relaxed. Not only is this bad for your health, it is actually a legal issue as well in many countries as you are working over time. Stop doing that today!
        Say no or delegate - If you get asked to split your attention between multiple areas or you feel that thet area you are in charge of is becoming difficult to manage within your normal working hours, then you should say no or delegate.  Saying no is always difficult since most managers are driven by status or to help others. It s however a very useful skill to master and it will save you a lot of stress. Just make sure you say no for the right reason and not to avoid stepping out of your comfort zone, because that is actually a good thing.

      This is very hard in some cultures and if you feel that this is impossible, then find a way within the situation you find yourself. A trick that you can try is to promote people that work for you or offer to teach someone what you do. Just make sure you make sure the person you delegate to also have their regular workload reduced or you will burn them out instead.
        Never try to lead someone that is not fully commited - Having people in your team that split their time is a cause for much frustration. No matter how much time they dedicate to your project you will never get that time because of the cost of content switching. You will also find the moments when they are not working on your project, no matter how rare they are, to be annoying and inconvenient. My advice is to never try to lead anyone who is not fully commited to your project because of this.  
      Developers & Designers
      Never split your work - There are times when you might be asked to split your work and my advice to you is to say no. No matter what split you have you will never be able to dedicate 100% time between the two. Each split will cost you a lot of time just for switching between them and the mental toll will be far worse then you think. If you split yourself 50/50 you will do 40% in each project and you will work 120%. You will constantly feel stressed and that you do not do the work you are supposed to. It will eventually break you down mentally so never accept a split work situation.
        Avoid meetings if you can - Some meetings you need to attend, but try to avoid meetings that are not necessary. The reason is that a meeting, even if it is just 30 minutes long, will completely content switch you from your work. Unlike a short interruption that cost around 10-15 minutes of lost time a meeting will cost at least double that. Some meetings may be even more disruptive causing fragmentaion of thought for hours afterwards as you try to focus on work, but have the new information or task in mind as well.
        Take time to clarify things - The biggest issue for most developers and designers is unclear requirements and unclear expectations. If you take time to clarify things, then you will save a lot of time. That is because not only will you wate time trying to find answers, you also suffer from content switching. This can make a simple question cost hours of focused work. Everyone have different need when it comes to clarity so do not rush sprint startups, requirement sessions or technical architect forums. Make sure everyone in the team understand what to do and why. This way you can focus on working without having to find answers or explain things to other members of your team.
        Agree on work environments - All teams have different compositions. Some need a lot fo focus, others less. Make sure you define wht your team needs and agree on how you will work. I have had teams that work with the hand so they just put up the hand to let you know they are busy. This way you can signal that the person have to come back later as you are deep into something right now. If that is still to disruptive then use a hat or something that indicate this before you even approach teh developer. In some cases it can be a good idea to assign a team lead or project manager to handle all outside requests to further reduce disruptions. Whatever your team need, make sure it is defined and agreed upon by everyone.  
      Insert yourself into the information flow - As testers it is sometimes difficult to know what is going on. This is because testers can be seen as an external part of the development flow. This usually means test comes in long after requirements and development planning, which is not only stupid from a quality perspective, it is also cause for frustration and stress. As testers you should sign off on all requirements and you need to be on top of development and deploys. So if you are not included in the information flows you need to be in, then make sure that you are. This way you do not need to run around looking for information or work within an isolated workflow. If you do not, then you will constantly feel stressed and frustrated.
        Agree on bug flow with developers - As testers you should not sit and verify browser compability or standard flows. These should already be well tested by the developers. If this is not the case then you will feel that you are just writing bugs all days and no development ever get past test. This is a bad situation and you should make sure there is a proper definition of done that prevent this.

      When you find a bug you often want to discuss this with a developer. Doing so is disruptive however and I suggest that you set aside two slots every day where you can go over the defects with the team when it does the least damage. This can be done directly after the daily standup and directly after lunch as that is also when many teams collaborate on code reviews and so on. Just agree with the developers when and how you will go over the defects to ensure the impact is as small as possible.  
      These are just a few small tips on how to reduce stress and what the cost is for stretching yourself thin by splitting your attention between multiple projects. Most of these may be most relevant to a certain group, but most of them are valid for all groups. Content switching and bad work processes cost billions every day and they cause health issues that should not be underestimated.
      Stress related illness is increasing and in many fields you can name at least one or two persons that you work with that have suffered from being burned out. In Japan there is even a specific word for working yourself to death: Karoshi. So be wary of the many ways that you can harm yourself unintentionally. One good start to protect yourself is to never accept working on multiple projects at the same time.
      If you have more tips, please share to help others avoid getting burned out.

      View full blog article
  • Create New...