A tweet from John Cutler and the ensuing thread struck a chord with me the other day…
“Amazed at how few teams (using #scrum) embrace the sprint goal, and the idea of a mini fixed-length / variable scope project. Wonder why that is?”
Some of the replies included:
“Personal Opinion: In a lot of places the ceremonies can become more important than the work and ‘predictability’ of delivery timing becomes currency rather than the value that is obtained from the delivery.”
“Because they are really working on a fixed scope waterfall project divided up into 2 week sprints? ”
“Is it necessary to have a sprint goal, if the Sprint scope is clear? In other words: is sprint scope not the sprint Goal?”
Sprint Goals (done well) are awesome
I’m a huge advocate of Sprint Goals — its one of my favourite parts of the Scrum framework. When teams best apply them, they can really help them focus, have a sense of purpose, and connect back to higher strategic goals. Intrinsic motivation front and centre at the top of each Scrum team’s task board! For such a seemingly straightforward topic, I enjoyed the discussion on the thread, as it explored many different interpretations.
Its intriguing how something seemingly so small yet so important can have so many different interpretations. Also how a goal can get confused with fixed-scope outputs, like confusing winning a football tournament with the number of corner kicks and throw in’s we won in the final!
It even got me thinking of my favourite movie…
The Scrum Time Paradox
Some of this confusion may stem from usage of what I think of as the Scrum Time Paradox. Remember in Back to the Future 2, when Biff stole the Sports Almanac, got rich from knowing all the future scores, and created a time paradox between 1985 and an alternate 1985? Chaos ensued! In common practice, its too easy for the Sprint Goal to fall into Biff’s alternate 1985.
Many interpretations of the Sprint Goal rely on previous versions of the Scrum Guide. For example, in older versions, in Sprint Planning it guided teams to first create their sprint backlog, and then craft their sprint goal. This this became a summary of the list of PBIs pulled into the sprint, or in worst cases — “Our goal is do all of this scope.”
In more recent versions of the Scrum Guide, this was updated to have a draft version of the Sprint Goal introduced before pulling in PBIs. We are starting with a goal, based off a higher level release or strategic goal (hopefully!), and then selecting the outputs needed to make progress against that.
It may seem like a tiny change, but the order of goal setting vs output creation can influence how we view a goal and how we view scope.
Going back to the future with sprint goals
The guide has evolved over time, based on inspection and adaptation. That’s cool, because a lot has happened in the 8 years since its first version, and Scrum has evolved. DevOps and continuous everything changed the world. Lean Startup got us thinking about outcomes and hypotheses and changed how we think about requirements. Donald Reinertsen’s work evolved how we think about product development. Learnings from Kanban evolved knowledge on flow and forecasting. Dave Snowden’s work on how we think about complexity in knowledge work. The list goes on.
When Scrum is no longer Scrum
The Sprint Goal fixed-time fixed-scope paradox is an easy trap to fall into, with things which are no longer Scrum. For example, a famous one being the idea of a Sprint Commitment. This term was retired from the Scrum Guide in 2013. The guidance since then is to forecast upcoming sprint work, and for teams to use the value of commitment to work together to achieve their sprint goal.
A subtle yet important change, as forecasting suggests that much like the weather, we will use all the data we have at hand to make the best informed guess we can as to what we will deliver. Empiricism. The winds may change —we may get feedback mid-sprint, or perhaps we learned something technically we did not know at the start. We can still achieve the goal, but with different scope than originally planned.
The sprint is a container for innovation
Here’s the thing — the timebox of a sprint can be a great forcing function to think creatively about how to achieve more outcome with less output than originally planned. After all, Agile is not about more efficiently delivering faster horses — its about delivering outcomes for customers and users with as little output as possible.
When viewed like this, this makes a sprint a fixed time, variable scope container, with the sprint goal front and centre as the outcome we’re trying to achieve as a team.
Escaping fixed-time, fixed-scope sprint goals
Here are 3 tips in creating effective sprint goals, that help keep the focus on the outcome of the sprint, and not into falling into the trap of a fixed-scope ouputs-driven goal…
- Relate it back to a higher level goal. If you’ve create a story map with slices, and/or use OKRs, these are a great basis to connect your smaller sprint goal to those larger goals. e.g. You have a goal to decrease dropoff on your checkout flow in slice 1 of your story map or roadmap theme. Your first sprint goal could be to decrease dropoff on the cart summary part of your flow. The team should be able to trace sprint goals back to roadmap goals.
- Check your user stories against the INVEST criteria — particularly around the “Negotiable” aspect. If push comes to shove in week 2 of the sprint, the timebox can be a great forcing function to think creatively about how to achieve more outcome with less output than originally planned. e.g. We’d like to enable the user to select an upsell — maybe a text link is enough for now, the fancier option could come later.
- Try out Roman Pichler’s Sprint Goal template — https://www.romanpichler.com/tools/the-sprint-goal-template/ — this is a nice thinking tool I’d recommend.
How does your team view sprint goals and scope within sprints? I’d love to hear your thoughts.