I'm new to Agile projects.
How do you manage the cost of bug fixing? Does the customer pays for that effort or the software factory?
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
It's really no different than in waterfall projects. When you hand it to the customer and say it's done, there's the implied statement that you've tested it and it is high quality. So, any bugs would be a flaw in development that the development team would own.
It's like if you had someone replace the brakes on your car and they made a mistake. You paid for it to be done right and they would be responsible for correcting the mistake.
The two big caveats to this would be:
1) If you have something in your contract with the customer that specifies otherwise.
2) If the "bug" is actually a change in scope. Like with waterfall projects, this is a grey area. Is it really a new feature or did you misunderstand what the customer needed? Is the development work small enough that the benefit of customer satisfaction outweighs the cost of the work?
Agile development teams own the cost of bug fixing. You generally don't get money from a customer for selling them bugs. In Agile, the focus on bugs should be empowering teams to pro-actively understand stories and done criteria to minimize the the likelihood of defects. When defects are discovered, Agile teams learn and respond to why the arose.
The $$$ negotiation between the team and the customer should allow enough compensation for the team to deliver a valuable, quality product. But quality to the customer should be sold as pro-active investments/practices including things like manual/automated testing, code reviews, TDD, refactoring, iterative delivery, CI, CD, and so forth.
Estimating stories to take bug fixing into account is re-active. What problem are you really trying to solve? Work with your teams to get them to understand the story and own quality delivery of it so that the risk of bugs is mitigated.
That said, there will always be bugs and the framework you use to deliver the software (Scrum, Kanban, Waterfall, XP, etc) will never lead to a 100% defect free product.
As to how to manage the cost...Work with the customer to determine the impact of the defects before fixing. Some defects are not worth fixing. Those that must be fixed result in reduced project scope. Be transparent with the customer to tell them when things are off track because existing features are not the quality they will expect. The customer will ultimately tell you what compromise to make. The main benefit Agile frameworks can provide in this arena is to reduce the feedback loop time and help minimize the $$$ interest rate on deferring defect fixes to the end of a project.
If there are defects (or i.e. bugs) are there in your software development team or i.e. the software factory needs to handle it internally. Its their cost. These bugs can be of different scales from minor to critical showstoppers. Ideally, the effort should be borne by the software house, working additional hours during the sprint to correct them.
But if you are smart enough, scrum master can off load some effort from bug fixing to next sprint, so the client pays for the effort on fixing them. Possible for minor and medium rated bugs but not for critical bugs.
In the "normal" case (Team developed something, but a bug was found), the team owns the cost of the bug. They already "earned" the story points for a story that was not entirely done as expected.
In case of a legacy application the team obviously cannot be held responsible for bugs that happened before the even had their hands on the code. The team shouldn't have to own the costs of those bugs.