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”.

Think.jpg

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)

 

 

Scrum’s “Blank Page” & The Purpose of this Blog

What’s the problem?

In a Wall Street Journal article in 2011, Marc Andreessen famously wrote “software is eating the world”. Given its dominance these days, we might also say “agile is eating the software process world”. And while it is true there are many flavours of agile, as we peel layers from the onion it is becoming clear that “Scrum is eating the agile world”. Most organisations use agile approaches for projects and most of those use Scrum (or a variant of Scrum).

In 2013 the Scrum Alliance alerted us to an alarming statistic about adoption of the Product Owner role:

24% of our participants have a Product Owner role that is in alignment with Scrum best practices, with that individual having the authority to set business priorities for the project and directly interfacing with the customer. 38% have a Product Owner who juggles priorities for multiple stakeholders and is acting in more of a liaison role. 20% of their teams were co-located, while 24% were distributed across sites or geography (Click here to read the full report)

In other words, only a quarter of those using Scrum have a Product Owner aligned with Scrum methods. Surely only a subset of this quarter are also effective at the role. So we can infer that maybe 1 in 5 (or even as low as 1 in 10) Product Owners are both aligned and effective.

This is a colossal failure!

At least some of the cause is that Scrum itself only vaguely describes the Product Owner role.

Blank Page

The Scrum Guide essentially leaves the Product Owner role as a blank page.

The Scrum Guide 2017 describes a Product Owner as “…responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” It goes on to say that “…the Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: … optimizing the value of the work the Development Team performs”.

Strategically and tactically, practically how does a Product Owner optimize the value of the work? The Scrum guide gives us no clue, so Product Owners are expected to figure it out for themselves.

Clearly many Product Owners are not figuring it out.

What can be done?

Traditionally the function that decides what to build has been someone with a job title like Product Manager, Product Marketer or Marketing Manager. The Scrum Product Owner role only really specifies (and vaguely, at that) the mechanics for communicating what to build to Development Teams.

It does not specify how to go about deciding what to build in the first place. In other words, the narrow Scrum Product Owner role is just one aspect of the function that decides what to build.

Practical advice and guidance on how to go about all the other aspects of the role is sorely needed.

The purpose of this blog is to elaborate on the business function of deciding what to build (as opposed to how to build it) by understanding the theory and more importantly, turning theory into practical advice.

Is this blog for me?

This blog talks to 2 audiences.

Techies are those who build software – developers, QA, architects, Scrum Masters, Product Owners, DevOps, Head of Engineering, COO.

The Business are those who decide what software to build – Marketing, Product Managers, Head of Product, CMO.

For the business:

  1. Does Product Management clearly articulate how development is connected to delivering value?
  2. Is there a clear understanding of each product’s roadmap and how it relates to commercial strategy?
  3. Are the voices of your customers heard loud and clear by development?
  4. Do your product releases always energise your customers and make them say “Wow!”?
  5. Do your organisation’s software projects always deliver what is perceived as optimal value?

For the techies:

  1. Does the business have a clearly defined and transparent process for adding new items to the Product Backlog? Is this process traceable back to the principles in The Agile Manifesto?
  2. Is development engaged and involved in Product Backlog refinement?
  3. Are requirements framed as a way to facilitate a dialogue between the business and development?
  4. Does your organisation clearly separate the what (the business’ role) from the how (development’s role)?
  5. Does the business continually explain how the development efforts – and changes in priorities over time – directly result in increased value?

If the answer is no to any of the above, you’ve come to the right place.

Housekeeping

A couple more points.

This blog is not only about Scrum. As we work through the theory and practice of the role that decides what to build (whatever it happens to be called in your organisation), it will become clear that this role can (and must) be flexible enough to work with any development methodology.

Feedback is always welcome. We learn best by having conversations, so this blog is best viewed as a conversation starter. Whilst every effort will be made to research facts and apply rational argument, claims and assertions are my own opinions and are subject to change as better information comes to light. In summary, please feel free to correct me or hit me up with better information you might have.