What Makes a Good Vision?

Agile methods pay lip service to vision, but they artfully dodge the important question of what a vision is.

For example, the Scrum Guide 2017 contains the word “vision” exactly once, in this sentence describing each product increment: “The increment is a step toward a vision or goal”.

A dictionary definition of vision: “An imagined idea or a goal toward which one aspires”.


What are the characteristics of a good vision?

Put simply, a good vision is a short and easily understood statement of the value a product will provide to its customers.

A vision should trigger a positive emotional response and it should state how you will change the world for the better.

Some good examples of vision statements:

  • “To organize the world’s information and make it universally accessible and useful” – Google
  • “To be the fabric of real-time communication on the web” – Skype
  • “To give people the power to share and make the world more open and connected” – Facebook
  • “Make people happy” – Disney (original)

Even though the last example is probably too generic, contrast it with the 2018 Disney mission statement:

“The mission of The Walt Disney Company is to be one of the world’s leading producers and providers of entertainment and information. Using our portfolio of brands to differentiate our content, services and consumer products, we seek to develop the most creative, innovative and profitable entertainment experiences and related products in the world.”

Clearly Disney has a bad case of corporate-speak. Their 2018 vision statement fails on every measure: it is not short, it is not easily understood, it does not appeal to position emotions, it does not explain the value customers will get, and it does not state how Disney will change the world for the better.

Don’t be like Disney in 2018.

The Power of Clear Sprint Goals

What does a product owner really do?

According to the Scrum Guide 2017, a product owner:

  • Is responsible for maintaining the product backlog
  • Helps the  team decide which backlog items to add to each sprint plan
  • Accepts (or rejects) backlog items and features resulting from each sprint
  • Works with the team to refine (clarify, prioritize) the backlog

If a Product Owner follows the Scrum Guide to the letter and focuses on just the above tasks, will this really optimize value the team delivers? What’s missing?

Use sprint goals to communicate intent

The best research into human communication tells us that we understand each other better through the use of stories, and a particularly powerful storytelling technique is the use of metaphors. How is the relevant to the product owner role?

A list of backlog items – like a “to do” list – is a great way to break a goal into constituent, individually achievable pieces. But without knowing what the goal is, a list of backlog items is missing a key element. What’s missing is the intent. With a clear goal, we communicate intent. Just as a picture can be worth a thousand words, a statement of intent can bring meaning to many backlog items.

The purpose of having sprint goals is to focus the team on the desired outcome, as opposed to simply implementing a bunch of discrete user stories. It helps provide the team with the why, in addition to the what, and helps to focus sprint planning on what really matters to deliver the outcome. Developers are smart people. Knowing why they are working on a given set of tasks will help focus their intellectual efforts.

Good sprint goals help the team focus on what matters, and can help the team deal with uncertainty when the product owner is not present.

Sprint goals also help facilitate stakeholder communication. Imagine coming across an executive at the office water cooler and she asks you what the team is working on. If you rattle off a list of backlog items in the current sprint, their eyes will glaze over from the detail. If you can tell them a coherent sprint goal though, your story is told effectively in a sentence or two.

Having goals encourages everyone to “think before you act”.


Tips for better sprint goals

Sprint goals can be of different types, for example goals might be to deliver a feature (“get the widget ordering feature ready for release”) or to address a risk (“ensure system architecture delivers adequate system performance”). And a single sprint may have multiple goals.

A good sprint goal clearly specifies intent and is measurable.

Some good and bad sprint goals:

  • “Complete the 7 user stories pulled into the sprint plan from the product backlog” (BAD: Does not specify helpful intent)
  • “Improve widget XYZ” (Bad: Vague and not measurable)
  • “Customers can recalculate a site annual budget in less than 10 seconds” (GOOD: Specifies intent and is measurable)