• Post author:
  • Reading time:4 mins read
You are currently viewing NBA Star Giannis Antetokounmpo’s Thoughts on Scrum

The NBA’s Milwaukee Bucks did not make it to the finals this year. Listen to what NBA star Giannis Antetokounmpo had to say about losing to the Miami Heat and about the failure of the 2022-2023 season.

So how does this relate to Sprints in Scrum?

Have you ever heard someone say “This past Sprint was a failure?”

What does failure mean in this situation? Is it about the team’s velocity being low? Is it the team not completing all the Product Backlog Items they took on in Sprint Planning? Is it the team not delivering a potentially shippable Product Increment? Or is it an unhappy stakeholder? What else?

I do not consider any of these failures. Scrum is all about empiricism and regularly inspecting and adapting. It is about speculating and validating. And it is about timeboxing to maximize learning, minimize risks, fail early, or deliver early and often. In Sprint Planning, we are speculating that what we are going to build is going to be valuable. We are speculating that the technical solution will work. We are speculating that we can complete the work within the timebox. And we are validating these things at the end of the timebox in the Sprint Review and Sprint Retrospective. We are constantly evaluating feasibility, viability, usability, and desirability and then pivoting by updating the Product Backlog accordingly and adding retrospective action items to our Sprint Backlog.

A lower velocity is an indication of our team’s capacity and a signal to not over commit.

Completing all Product Backlog Items is not the objective of the Sprint. The objective is to deliver a Product Increment based on a Sprint goal tied to an overall product vision. The Product Backlog items help us accomplish this goal but the items in themselves are not the goal.

Not being able to deliver a potentially shippable Product Increment might be due to an incorrect technical solution (a good thing in failing fast and discovering this early) or it might indicate a need for better engineering practices (TDD, continuous integration, continuous deployment, automated testing, etc.) and a review of the team’s Definition of Done.

An unhappy stakeholder might indicate an invalidated hypothesis (a good thing in failing fast and discovering this early), or a misunderstanding of the requirement and a need for more ongoing Product Backlog Refinement.

The entire Scrum framework is based on empiricism and the pillars of transparency, inspection, and adaptation. A statement indicating that the Sprint was a failure goes against the notion of empiricism and what Sprints are all about. It also demotivates the team and will likely lead to trust issues, a lack of innovation, and a lack of transparency. Without transparency we lose the ability to properly inspect and adapt to ensure delivery of value and continuous improvement.

When a Sprint does not go as planned, we should go into the retrospective and reflect back on what happened, learn from it, and adjust accordingly. A Sprint is about continuous learning and continuous improvement. Each Sprint brings us one set closer to our overall Product Goal.


To go beyond the fundamentals of Scrum, consider taking an A-CSM class where we dive deeper into the Scrum Master’s role in servicing the Product Owner, the Developers and the organization, and learn facilitation and coaching techniques that help you over common Scrum anti-patterns in order to help your team and organization succeed.