We estimated the effort to accomplish our software enhancement on the basis of the original feature working as designed. When testing we found it had significant defects and did not work as designed. We rolled back all our changes and proved the original code had these defects at release. The original team claimed otherwise despite us proving it on unaltered code.

We found the source of the defects but are not allowed to remove it. Instead we have had to absorb fixing all the affected features (well beyond the original scope of our story) and now are being asked to test all the old features.

The scope of the testing is enormous. How do get the other teams to help test their original work again. They all claim its nothing to do with them despite us proving the functionality didnt work in the released version of the code.

  • 12
    A supervisor is going to need to step in. Take this to your boss. – paparazzo Oct 19 '18 at 14:53
  • 2
    What exactly is making this a problem? Are you being forced to do overtime for this? Are you being held responsible for this somehow? Fixing and building things is your job; if the company thinks your team is best suited for it, that shouldn't have to be a problem. – Erik Oct 19 '18 at 15:21
  • 2
    If you are being asked to do all of this new work, are you still expected to do it in the same amount of time? – David K Oct 19 '18 at 15:40
  • 1
    Where was your SQA team when the company first released? (with defects) – Sandra K Oct 19 '18 at 16:20
  • How is application ownership handled in your department? Who owns the technical debt your team has found? The answers to those questions are going to decide whether this is in scope for your team or not. Either way, cut these as new stories.. not work on the same ticket. – DanK Oct 19 '18 at 19:42

I would say involve your Scrum Master and Product Owner. Ultimately the Product Owner should be the one to make the decision and prioritize any new work that results.

  • That was exactly what I would have written. If improving the old code is relevant and, the PO needs to prioritize with the customer. – Sascha Oct 21 '18 at 17:42

When making an estimate it is reasonable to assume features work as designed. You should test critical features but cannot test all features.

It is not reasonable for you to have fix existing bugs and test all features if that is not in the scope of work.

In the scope of work / estimate you should always include this assumes all features work as designed.

Does not sound like you are going to get very far going directly to the other team.

You need to take this to your boss with proof of prior bugs and a revised estimate of scope extension. You may get no where with your boss and if so need to just do what you can. It might be he has been told this is how it is by his boss. If the project comes in over budget then need to explain the extension to scope.

It may make sense for your team to fix and test rather than wait for another team to fix existing bugs. Not fair if you are not allotted more time or resources but sometimes life is not fair.


You are an agile team. If that's for real and not for show, in the end you are supposed to determine the answer to that question.

Log it as one or more defect tickets for the bug(s). Then determine what the "right thing to do" is in your situation - is it to break the sprint and take it on now, or to put it at the top of the backlog for next sprint, or just log it for later? Collaborate with each other - technical staff should provide the impact and LOE (level of effort) of fix, the product owner will contribute to the prioritization and understanding of other time commitments involved. Then do it now, or later, or never, based on what the right thing is to do for that service and its users and your business.

Being Agile is empowering but it comes with responsibility. If one of my teams said "well we shipped with the critical bug because, you know, we saw it but no one told us to fix it," there would be regrettable consequences.

I find it very disappointing that other answerers either don't know much about Agile or work in "fake agile" environments; "the boss tells you what to do" is old school BS that is at odds with a well operating agile shop.


What should have happened: You had tasks that were supposed to be rather easy to handle, not consuming much time. Then you found out that due to existing bugs, finishing these tasks successfully (without showing bugs) was much harder than thought.

You should have added a new task: "Fix existing problems". Mark it as blocking your tasks, mark your tasks as blocked. So you can't finish your tasks. You pick other tasks, and meanwhile your scrum master contacts whoever is responsible for the blockage and asks thems to fix it asap.

If, as you said, there is a refusal to change the source of the problem, then you need to design how to implement your tasks in the presence of the existing bugs. This will be obviously much more complex. BTW. It's a task in itself that will take some time. Then you add all the additional tasks which are caused by someone's stubbornness, and estimate them, and perform all those tasks.

As the end result, nobody can say "you did 10 days worth of work, but it took you 30 days", but you say "what was supposed to be 10 days worth of work was actually 30 days worth of work, because others were not cooperative, and we did the 30 days worth of work in 30 days".

The point is that it doesn't really matter who does the work. The point is that you show evidence that your workload greatly increased, and you handled it.


Nothing as part of the team you can do, or should, i guess There is no such things as extra work :)

Your boss / team leader have options, depending on the nature of your engagement, whether you part of the company or hired team?

Build a the new tasks list incorporating all the needed tasks and update the deadline to the project, and

  1. report up the chain of command in the company to his boss


  1. come back to the customer with new time line, budget and bill for work done

Update: If you disagree, please dont just down-vote, drop a line in comments We can discuss it

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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