A Scrum Story: To Deliver Or Not To Deliver? That’s The Question


In this article I want to share a story about one of the Scrum Team I handled.
I’m a Scrum Master in the team and I will share the story from my point of view.

The Scrum Story

incompleteIn one of my Scrum Team, we faced a situation where the sprint increment was not “perfect”.
We just realized that there was another product using the function we created in the sprint. Unfortunately we found that exactly one day before the delivery and the function was not prepared for that product which might cause an issue if we deliver that.

The issue that might happen is not big and only happen if both system using the function at the same time, same minute, same second.
Which is rare, right? But still, it might occur.


There were three options:

  1. Cancel the delivery and handle the issue in the next sprint.
  2. Deliver anyway with the hope that the issue will not happen for the next two weeks until we fix it in the next sprint.
  3. Deliver partially and hold the related user story for the next sprint.

Few hours before the Sprint Review, we still stick on the 2nd option, because the possibilities that the same time function usage is very rare.

But on the Sprint Review the team discussed with Product Owner for all the possibilities might happen and all the workaround they need to do to fix the issue if it happens.

After some considerations, Product Owner decided to go with the 1st option – Cancel the delivery and handle the issue in the next sprint.

It was a wise decision taken by the Product Owner.
Business users complained, saying that our delivery is not on time and slow.
No problem, we explained to them about the possibilities might occur if we continue, and they had no other option than agree with our decision.

The team continued the next sprint and fixed the issue. After the time box end, we delivered the increment to production and there was no issue found in both product.


wise decisionSometime we might find that some things block us from moving forward and that makes us feel that we’re moving slower than expected.

But delivering unfinished or “problem candidate” increment will definitely slowing down the project.
Maybe not in the specified sprint, but definitely on the upcoming sprints ahead.

Development Team will need to fix the issue caused by those kind of increments in the upcoming sprints.
Product Backlog will be stained by “bug” backlogs.
Indirectly, that will cause the delay in the complete product delivery.

So, “To Deliver Or Not To Deliver?”
Your call. Make sure you make the decision that you will not regret.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s