Skip to main content

Who is responsible for mistakes

Last post 07:45 am March 7, 2020 by Simon Mayer
6 replies
05:59 pm March 5, 2020

Hi All,

I work with a software company that uses scrum.  They develop the sales and purchasing software for our company.  Recently they delivered a ticket that was incorrect, meaning my needs were clearly outlined in the Jira ticket but they missed it and developed incorrectly, so it needs to go in a new sprint, which is fine.  My question is, who is normally financially responsible for something like this?  Does the customer pay for the next print?  Or should the software company cover their mistake?  A mistake they openly admitted was their fault.  I am somewhat a laymen in this so I do not want to fight it unjustly, I just want to know what is an industry norm.  Thanks.


09:01 pm March 5, 2020

What did they commit to delivering?

Did you help them to inspect and adapt their progress towards a shared Sprint Goal?


09:49 am March 6, 2020

Its the responsibility of the whole team. Everyone has a part to play. SM + PO + Devs. There is no such thing as "their mistake". Scrum does its best to ensure frequent Inspection (and if needed Adaption) takes place. You story sounds like as a whole, that could have been better. Is this a mistake? Is it someones fault? Or is it the Inspection and Adaption of the process?

Who should pay for what under what circumstances should be handled on SLA or contract level, and not be a factor in your agile  process.


05:03 pm March 6, 2020

I know if its tickets/issue kind of support project then SLA would have already outlined whose pocket it should be . 

but time and money or fixed cost project : I have seen customer bearing the cost somewhat. However based on frequency of such instances, customers do give you feedback and your relationship with them get on stake. 

In this situaltion , I will really nail down the cause of misinterpreted requirements and how often does it happen. 

GIve some flexibilty to your implementation team ( room to breathe) . Human make mistakes. 

looking forward to see what other say. 


06:13 pm March 6, 2020

The Scrum team pays for the mistake because it was a Scrum team mistake.  In your description it seems you are the Product Owner.  Your part of the mistake was not making sure that the problem was correctly understood by the Development Team before they started.  It also sounds like you were not involved in the process after the Sprint started.  That is a mistake made by the whole team.  The Development Team made a mistake by not involving you and providing you insights into what was actually being built while it was being undertaken.  The Scrum Master made a mistake by not coaching the Scrum Team on the value of communication, openness and transparency.  So the entire Scrum team made a mistake.  But it is only a mistake if you don't learn from this situation.  Inspect it, discuss it, root cause analysis how the situation occurred and then implement steps to prevent it from happening again.

As for as actual cash/money, as @Xander Ladage said, you will have to rely on contractual agreements.  Especially since you refer to the "software company" which leads me to believe that the Development Team is an external company.  But to prevent this type of "mistake" from recurring, you need to fix the reasons by focusing on the situation. 


09:06 pm March 6, 2020

@all thank you so much for your replies.  Let me give a little more detail based on your responses - So the product was built by a company for a specific industry.  The company has, since its inception, offered customizations to cover the unique needs of different customers in our small industry.  My company is their largest customer and are unique in an already unique industry.  They introduced the scrum method to us at the beginning of the year so it is all pretty new to me.  The way the have us work within it is; we meet to discuss the tickets coming up in the next sprint, make sure we are all on the same page, and then we don't hear/see/work with them regarding those tickets until the sprint is complete. They have never included us in the actual sprint. They do not keep us posted on progress, have us test or even look at what they are doing until it is "complete".  So in this one instance the "completed" product is incorrect though it was clearly outlined by their team in their written solution, they just missed it. But I now have to wait 2 weeks for it to make it in to a new sprint and am being told my company has to cover the cost.  I just want to understand if this is normal with this type of method?  Based on some of the previous responses it seems they should be including us in more steps than they currently are.  

Prior to this we were quoted total hours for a ticket and paid those hours.  If something was delivered non-functioning or inconsistent with the Jira ticket, depending on whose mistake it was (our vs theirs) we would work out who covers the additional hours. 

We are trying to budget the projects and want to see which method actually will work for our company.  Thank you all for any info.


07:45 am March 7, 2020

The first thing that comes to my mind is this line from the agile manifesto:

Customer collaboration over contract negotiation

As the largest customer, your company is presumably in the strongest position to drive how this conversation with the supplier goes.

It's good to be aware of contractual obligations, and you will need to decide whether trying to enforce that is a wise decision.

I would suggest to consider the value for both parties in resolving this in a collaborative way. In the short term, just looking at this one incident, perhaps you can find a mutually acceptable way forward in terms of how this is billed, and how the remaining scope is handled.

Longer term, this can actually be an opportunity to work much better for your two companies, and it might even allow the supplier to work better with its other customers. Perhaps you have tried to be involved during the sprints, but from now on, you can make the case – with a real life example – of why it would be valuable to do so.

If the outcome of this incident is painful for either party, you might see further upfront negotiation and rigidity with any future work. That might sound appealing in some ways, but it serves primarily to heighten feelings of "them and us", and makes collaboration even harder to achieve.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.