0

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?

Improve this question
2

4 Answers 4

Reset to default
2

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?

Improve this answer
2
  • You know that in software development the bugs exists allways, so, taking in count your advice, I will estimate the tasks adding some buffer to cover the bugs, because they occurrs.
    – NahuelGQ
    Mar 13, 2015 at 17:18
  • Usually in agile, when the team estimates the story size, one of the factors is complexity and risk of bugs can influence that. The idea of that estimation is to say how much effort it will take to get the story completed and properly working, so if it's something with a higher risk of needing more work, testing, and debugging to get right, that would result in a larger story estimate. I would caution that this is different than simply padding stories to account for work generated by quality problems.
    – Daniel
    Mar 13, 2015 at 18:29
1

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.

Improve this answer
0

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.

Improve this answer
0

It depends:

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.

Improve this answer
2
  • I am not sure this answers the question. The OP was not asking who as "responsibility" or "ownership" of the bugs, but which party bears the costs, i.e. who actually pays for the bug fixing, who gives up hard cash.
    – Marv Mills
    Mar 17, 2015 at 13:37
  • 1
    You are right, I'm having a different perspective on this. Nevertheless I think this also applies for the question who has to pay. If the client hands you a crappy piece of code, he will have to pay for the fixing.
    – Nitek
    Mar 17, 2015 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.