top of page

5 things I learned about Scrum from Star Wars

If you are a Star Wars fan like me, then you know that Star Wars is more than a story; it’s an Epic which holds many important life lessons. Below are the top five things I learned about Scrum from Star Wars.

#1 Do or do not. There is no try.

Star Wars: Episode V. The Empire Strikes Back. 1980.

One of the most memorable quotes from the Star Wars franchise comes from Episode V: The Empire Strikes Back, when Yoda demonstrates to Luke that he must believe in the Force to use the Force. In this sequence, Yoda says to Luke, “Do or do not. There is no try.” I think about this when teams work on delivering a Done increment each Sprint.

Sometimes, a team comes to the end of the Sprint to find that not all Product Backlog items (PBIs) meet the Definition of Done. In these situations, teams often ask me whether they should include the uncompleted PBIs in the Sprint Review, given the team did spend time on them.

The answer to this question is NO. Here’s why.

According to the 2020 Scrum Guide, the moment a PBI meets the Definition of Done, an increment is born. Not only is that Star Wars-level poetic, but it’s also very practical. The purpose of each Sprint is to deliver a Done increment. If teams take credit for partial work, it can cause stakeholder confusion. They might believe that the work the team shows at the Sprint Review is Done (completed).

For example, in “Software in 30 days” by Ken Schwaber and Jeff Sutherland, the authors tell the story of a Scrum Team that demonstrated work at the Sprint Review that was not actually integrated into the main codebase. In the story, the Product Owner decided to release the work after having seen it demonstrated at the Sprint Review, only to discover that the work was not, in fact, releasable.

Demonstrating work that is not Done causes confusion and opaque measures of progress.

The Definition of Done is a common understanding of all the work the team needs to complete before they can consider each PBI Done. A Definition of Done might include ensuring successful unit tests, a completed code review, code merged into the main code branch, or that the codebase was integrated into any other systems.

Before the team shows a PBI at the Sprint Review, it should meet the Definition of Done. As Yoda would say, “There is no try—it’s either Done or not Done.” Include only Done PBIs at the Sprint Review.

#2 Difficult to see. Always in motion is the future.

Star Wars Episode V - The Empire Strikes Back

Organizational theorist Ralph Stacey designed the Stacey Matrix (below) to determine when Agile is a good fit for a given business problem.

According to the matrix, four levels of complexity describe business problems: simple, complicated, complex, and chaotic. The level of complexity depends on three factors: requirements (whether they are known or unknown), technology (whether the solution is close to certainty or far from certainty) and people (the greater the number of people, the more complex it is to support the Product). Stacey uses these three factors to classify a business problem as simple, complicated, complex, or chaotic. Agile methods work best in complex business situations where more is unknown than known.

In complex environments, it is difficult to predict the future. That’s why Scrum, the most popular Agile framework, was founded upon empiricism, which means making decisions based on what is known.

The three pillars of empiricism are transparency, inspection and adaptation. The highest performing Scrum Teams enact each of these pillars in Scrum’s five events.

#3 You must unlearn what you have learned.

Star Wars: Episode V - The Empire Strikes Back

In Star Wars, Episode V, Yoda explains to Luke that to master the force, he must unlearn what he has learned. This quote comes to mind when I think about individuals working together on a truly cross-functional team for the first time.

According to the Scrum Guide, “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” For many of us, this is the opposite of how we are used to working. Taylorism has taught organizations the value of keeping everyone busy by creating highly specialized teams that hand off their work to other specialists, much like an assembly line. However, the assembly line model does not fit complex work. In environments where more is unknown than known, an Agile model is better suited. Using Scrum, teams focus on value delivery above keeping everyone busy. Scrum Teams optimize value delivery by possessing all of the skills required to deliver a Done increment of usable product every Sprint. Cross-functional teams reduce hand-offs and ensure that teams make better decisions about how they approach the work of the Scrum team.

Many organizations form teams around specializations rather than cross-functionality. For example, Java developers might exist on one team and report to the Java team manager. Business analysts are on another team and report to the business analyst manager. You get the idea.

Scrum Teams are different. In Scrum, teams are cross-functional with all the skills needed to deliver value to the customer. The skills required depend on the product the Scrum Team is supporting. According to the 2020 Scrum Guide, “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product can be a service, a physical product, or something more abstract.”

Is your product a .net website? If so, the Scrum Team might require individuals with skills in HTML, .net and back-end code such as C# or Visual Basic. Alternatively, if the Scrum Team is supporting a human resources department, Developers on the Scrum Team may require expertise in recruiting and compensation.

A common assumption is that cross-functional teams are larger, but that’s not necessarily true. Scrum Teams typically have ten or fewer members. However, cross-functional teams may cross technology silos.

Does this mean that a transition to Scrum requires wholesale reorganization and realignment of all reporting relationships? Not necessarily. The Scrum framework guides how Scrum Team members work together but does not necessarily impact reporting relationships.

#4 Many of the truths that we cling to depend on our point of view.

Star Wars Episode VI - Return of the Jedi

In Star Wars Episode VI, when Luke accuses Obi-Wan of lying to him about his father's death, Obi-Wan gives perhaps the flimsiest defense of all time to Luke, saying that he wasn’t lying from a certain point of view. While this reasoning might seem lame, in reality, sometimes the right thing to do does depend on perspective.

What seems like a great solution approach to a senior executive might not be the best way to achieve organizational goals in reality. That’s why Scrum Teams are self-managing, meaning that they (the ones closest to the work) decide who does what, when and how. To help Scrum Teams make the best decisions, the Product Owner communicates a vision and Product Goal, which guides Developers in determining how to deliver the Scrum Team’s work.

#5 A Jedi must have the deepest commitment, the most serious mind.

Star Wars Episode V - The Empire Strikes Back

In Episode V, the Empire Strikes Back, when Luke is trying to convince Yoda to teach him the ways of the force, Yoda pushes back and points out that Luke is not embracing values like commitment, focus and openness.

The 2020 Scrum Guide includes five values that are important to every successful implementation of Scrum. These values are courage, commitment, focus, openness, and respect. The more I practice Scrum; the more important these values appear to me because I have seen how impactful living the values is on the Scrum team. The highest performing Scrum Teams embody these values in their working relationships and live these values in each of the Scrum Events.


If you are a Star Wars fan like me, then you know that Star Wars is more than a story; it’s an Epic (pun intended) which holds many lessons. It turns out that many of those lessons parallel what we can learn from Scrum. These lessons include the importance of delivering a Done product and the role that values play in doing work well… not to mention the fact that the re-release of Episodes IV, V and VI were an object lesson in the fact that adding new features does not always add value.