Skip to main content

Agreement ≠ Commitment

Last post 10:29 pm March 2, 2026 by Mathias Tambo Njumbe
5 replies
02:21 am February 28, 2026

Hello Community,

As a Scrum Master, I have observed that the team repeatedly fails to follow through on agreed actions. What is the most effective course of action to address this issue and improve delivery?

Thanks for your inputs.


03:42 am February 28, 2026

Has this matter been discussed in a Sprint Retrospective?

  • It's possible they aren't in a position to make any commitments for themselves, if organizational constraints hold them back for example.
  • What are the consequences of the repeated failures you describe, and who feels them?

11:05 am February 28, 2026

When the team "repeatedly fails to follow through", are they failing to start or failing to achieve what they agreed to do?

However, as Ian mentioned, I'd point to the Sprint Retrospective as the place to understand why this is happening and what ideas the team may have to improve.


01:40 am March 2, 2026

As already mentioned, the Retrospective is a good place to start.

What you describe often points to overcommitment, as also alluded to in previous posts. Teams sometimes put forward an ambitious plan to gain approval or attempt to rebuild confidence after a previous Sprint failed. Ironically, this can lead to the same outcome again and again.

It gets worse when the plan is effectively decided for the team. If expectations are set externally and the team feels they cannot challenge them, they will agree publicly but fail to deliver. 

The real issue may not be capability, but courage. The team needs to be open about what is achievable, commit to a realistic plan, and focus on finishing it. Most importantly, they need the courage to push back on unrealistic expectations.

This problem is actaully common. Without honesty about capacity and constraints, the pattern will repeat. Teams need to build a habit of succeeding, even if that means starting with less ambitious Sprint plans and get into the habbit of delivering them consistently.

 

 


09:39 pm March 2, 2026

Mathias, what others have said is spot on, and I would present it in 2 bullet points

  1. Does the team know they have a problem? and have they discussed (resolving) it?  this goes back to the retrospective points.
  2. Root cause - others brought that up as well.  As you discuss and resolve with the team, make sure you go back to the root cause. Solutions could add more problems if you aren't understanding the cause of symptoms.  And this case is the most dangerous one.

Is it caused by capacity, capability, cultural, dependencies,... issues?


10:29 pm March 2, 2026

@Ian, absolutely, there are significant consequences, including eroded trust, wasted meeting time, and increasing frustration, to name a few.

I agree that the retrospective is an excellent opportunity to address this issue. What are some effective strategies we can implement to improve this situation?

@Pierre, thank you for your insightful contributions!


10:31 pm March 2, 2026

@Issam, great points, thanks


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.