Increment defect

It sounds like there is work remaining to be Done which ought to be accounted for in the Product Backlog. If the Developers agree that there is a quality problem, they will need to improve their Definition of Done so similar remedial work will not be necessary in the future.

Thanks for your response. That sounds right. But what if the final product is released and then the customer comes back to the same team who is working on another product. Are the developers still accountable for the defects of the previously released product? Or would they not get involved as it was already delivered and now they are focusing on the new product. How do they tackle this situation as the stakeholder is the same.

"The Product Backlog is an emergent, ordered list of what is needed to improve the product." The work to fix this defect is something that at least a subset of the stakeholders or product users believe is needed to improve the product, so it would go into the Product Backlog. Since it is in the Product Backlog, the Product Owner would order it among all of the other Product Backlog Items. The team would refine the work and it would eventually come up for Sprint Planning, where it would be designed, developed, integrated, and released for use by the stakeholders.

There are some open questions, though.

Since this is a defect, should the Product Owner interrupt the team's current Sprint? This depends on the severity and impact. If it is a critical issue, the Product Owner may decide to talk to the team about including it in the current Sprint. Otherwise, it can go in an appropriate place on the Product Backlog. I believe the Product Owner should have the discretion to decide if it's worth talking to the team about, but the team, being responsible for the Sprint Backlog, has the final decision on if they can take on the work within the Sprint and what the impact to the Sprint Goal would be if they do.

If the defect is on the Product Backlog, how high should it be ordered? Some teams strive for zero defects - known issues are always addressed before working on new features or functionality. Other teams may consider who is impacted by the defect, the effects of the defect on the system and the users, and any known workarounds to determine if it's more valuable to fix the defect sooner or defer it for later.

How can future defects be prevented? The retrospective is a good place to talk about defects that are slipping through the development process and being found by customers or end users in production. For more serious or impactful defects, performing an in-depth root cause analysis may be helpful. The team should probably find some opportunity to look at the defects that they are missing and determine if they need to make any changes to prevent future defects from going downstream.

Thanks Thomas. But what if the product is different. As in, the team is working on a completely new product and then the customer comes with a complaint about the product that was released earlier. Will the product owner include that in the product backlog of the new product being built? That would mean that the product goal would not be unique and in conflict with the goal of the new product right? Would the developers still be responsible to fix the defects of a product they developed and released, even if they are working on  a completely new product which has no relationship with the old Software? Wouldn't this impact their commitment towards the new product goal? What happens in this scenario? Please advise.

The Developers are always accountable for the quality of the Product, including any defective work they might create. Those defects represent technical debt which should be accounted for on the same Product Backlog, since that Product is evidently not complete and has work that remains to be Done.

The Product Owner is accountable for the value of the Product over its lifetime, including all investments being made. He or she will therefore need to decide if it is worth resourcing additional Sprints in order to pay off the technical debt that has been accrued. The whole Scrum Team will need to improve the Definition of Done and the Developers' ability to make that commitment, such that no further technical debt will be incurred.

I can't tell you if the developers remain responsible for performing maintenance on the product after it's released. That depends on the agreement between the customers of the product and the developing organization. Depending on the situation, there are a number of possibilities. Perhaps the original developers will perform maintenance activities. Perhaps there will be a support team to triage requests for this or multiple products and create fixes for issues. Perhaps the customer will find a new organization to perform maintenance or development.

Figuring out who will fix the problem is the first step, but it's not really one that anyone can help you with. This is up to your organization to figure out how to provide maintenance for products that are no longer under active development. Maintenance doesn't just include defects, but perhaps there will be suggestions for enhancements or routine maintenance on the product to ensure it continues to be usable for as long as necessary.

I wouldn't recommend putting the defect in the Product Backlog for a different product. Each product should have its own Product Backlog, which represents work for that specific product. The defect would be added to the Product Backlog for the product that has a defect - if the Product Backlog was empty after the delivery of the product, then it would now be a Product Backlog of size 1.

Thank you so much Ian and Thomas for your valuable comments. I learned something new!!

Let me pose a situation that might help you picture this.  

You own a 2019 model of a car.  Your car has a problem that needs to be addressed.  If you took it to a dealership that sales that brand of car, would you expect them to fix it even though that year model is no longer sold? From the manufacturers view point, it will not be the people that built the car that will fix it but it still should be fixed by someone that the manufacturer has faith will be able to fix it. From the customer's point of view you are the dealership for the product that they are using and they expect you to fix it or aid them in finding someone to fix it. 

Software is a little bit different than cars.  With cars, companies can acquire a part and copy it, or learn how to disassemble/reassemble the car so there are many places qualified to fix it.  In software, a company usually owns the code base, it is not publically available and it is not something that can be modified by others.  So it usually requires the company that wrote the code to update the code. 

Now, having said all of that, the Scrum framework expects that as long as a product is in use and is considered viable by the company that owns it, a Product Backlog will exist for that product.  It also assumes that there is a Scrum Team that will work on items from the Product Backlog.  If your organization has decided that the product is still viable, they should make decisions on how that Product Backlog will be addressed. 

The Scrum Guide does not provide any definition of what a Product is or how a Product should be managed.  However, it provide this statement in the section that discusses the Scrum Team.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. 

The way you describe your situation makes me think that your organization does custom solutions based upon contracted services.  After a custom solution is delivered and accepted by the customer, your internal teams move on to another contract.  In the past where I have worked in that model or been a purchaser of services, the contract always had some verbiage on how support would be done.  Also the company doing the custom work would have a mechanism/procedure in place for support activities.  This entire situation is a procedural issue that is outside the scope of the Scrum framework.

Thanks Daniel.