Sprint Goals in Practice
First published in The Agile Zone, 14 December 2015
"Onward! onward! must we travel? When will come the goal?Riddle I may not unravel, Cease to vex my soul."
― Adam Lindsay Gordon, Finis Exoptatus
Sprint Goals: A Mystery to Many
A couple of years ago I wrote about a dirt-simple agile maturity model I sometimes use. It doesn’t require me to dig into things and find out whether or not value is truly being delivered to stakeholders, or even to examine a team’s metrics. It’s much more immediate than that because it is blatantly culture-driven, and the cultural dynamic of a group can be assessed relatively quickly. All I do is to count up the agile practices I see a team actually following. If daily stand-ups are being held for example, then that may be an elementary indicator of a team's agile fluency. I don’t care so much about what is done or said, as long as people leave the stand-up with a renewed sense of shared enterprise that will last them for the day. Sprint planning sessions are also a useful indicator in cases where the Scrum Framework is supposedly being applied. I don’t care so much about the planning format or who says what. Have they as as team agreed an actual sprint backlog, determined that it is achievable, and planned enough of the associated work to at least let them start development? That’s the key. Beyond these simple measures, teams which conduct reviews and retrospectives, instead of ditching them over the side in the mad rush to meet a deadline, may arguably be said to have evidenced a greater level of agile discipline and control. Furthermore, if teams don’t slur these practices together, and can demonstrate the ability to separate essential concerns, then that is a higher accomplishment still.
What though, is the pinnacle of achievement in this quick-and-dirty system of charting agile proficiency? Well, there is one criterion which, I believe, can and does betoken a capital degree of aptitude. The superlative consideration is this: "Has a sprint goal been articulated...and if not, can the team explain why not?"
Many teams struggle with this particular practice. Teams which might otherwise demonstrate great skill, and which might adduce track records of delivery that span many years, often puzzle over what is even meant by a “sprint goal”. I’ve heard teams claim that their “goal” is simply to complete the work on their sprint backlog, so they can then take on new work from the Product Backlog. When I point out that this is a poor reason to batch work into a second backlog at all, team members will shift uncomfortably from one foot to the other. Their less mature counterparts typically remain more sanguine. They often assert, with disarming candour, that their team's “goal” has little to do with backlogs at all, and that they simply hope to survive to the end of the Sprint, with membership and sanity intact.
So what is it about "sprint goals" that proves so vexing? Why do they prove a riddle to so many...and how might that riddle be unravelled?
Understanding the Sprint Backlog
Firstly, let's clarify the purpose of the sprint backlog, as it is described in the latest (2013) version of the Scrum Guide.
A sprint backlog is a forecast of the work that the team will need to do to meet the "sprint goal." Completing the work is not the "goal" in itself...it must serve a greater purpose. The sprint backlog, as a forecast of work, will include selected product backlog items (PBIs), and a plan for achieving the goal. That plan is often represented as tasks, but it doesn't have to be. The plan could be a very traditional management artifact such as a Gantt chart...scrum is quite agnostic about what a team's plan ought to look like. What matters is that the plan can be easily revised by the team, and provides transparency over the work that has been done and remains to be done during the Sprint.
In other words, the sprint backlog consists of two things: selected PBIs and an associated plan of work. The backlog is mutable, because it must always reflect the latest understanding of what the team must do to achieve their goal by the end of the sprint. Each day the development team will hold a daily scrum (or "standup") during which they refocus their combined efforts on meeting the goal, and replan as needed. The whole sprint is predicated upon achieving that "sprint goal"...if the goal becomes redundant, the sprint may be cancelled. So whatever the "sprint goal" is, one can almost detect an odour of sanctity about it. The sprint backlog, including the selected PBIs as well as the tasks, may change in order to meet the goal. That's where the sense of "commitment" lies in scrum...it's the goal that ought to be committed to by a team, and not the sprint backlog itself.
Moreover, the sprint backlog is wholly owned by the development team, while the goal is shared between them and the product owner. It must be agreed by them during sprint planning. Therefore the goal is not a component of the sprint backlog, but is a point of reference around which the backlog may be replanned and changed.
Understanding Sprint Goals
Now we're starting to close in on what a sprint goal really is, and the purpose it serves. Let's turn to the Scrum Guide and see what it actually has to say on the matter. The goal is described as a "coherence" which "provides guidance to the development team on why it is building the Increment." This is a recondite definition, and perhaps a bit abstruse, but we can figure it out from there. A sprint goal is the purpose behind the particular selection of work in the sprint backlog. It justifies the selection and makes it congruous. Because of the goal, the selection will result in an increment that is worth releasing as a discrete artifact, and which provides clear value above and beyond the chosen PBIs. In short, a sprint goal will make the sprint backlog more than the sum of its parts.
For example, a sprint goal might correspond to a useful feature which can be released to customers. The individual stories themselves might not be useful if delivered in isolation (add, remove, list contents), but the feature itself (perhaps a shopping cart), may indeed be of use. The goal is closely allied to the concept of a minimum viable product in lean startup terms. It may be something that can be released, like a feature, but it might also be something which simply allows an hypothesis to be tested, in order to limit risk and reduce waste.
This is a crucially important point, because it underpins the very rationale for the scrum framework. Scrum is designed to facilitate the development of complex products in environments of high uncertainty. If a discrete goal can be achieved by releasing an end-of-sprint increment, then the associated batch of work (the sprint backlog), can address greater risks and challenges than individual PBIs are able to target. More substantial business risks can thus be framed and mitigated on cadence, each and every sprint. In essence, a sprint goal is a business risk mitigation construct. Work is batched in order to mitigate significant risks that are identified and agreed, every sprint, with the product owner during sprint planning. The batch itself is mutable towards that end, and is replanned as necessary to meet the goal.
What we are getting at here is that the whole purpose of a sprint is to meet a sprint goal, and scrum is framed to support sprint-based delivery. Take away the sprint goal and the rationale for using scrum disappears with it. You might as well operate on the basis of continuous flow. Without a sprint goal to meet, sprint backlogs can serve no useful purpose.
What Does This Mean to a Team In Practice?
Many teams that consider themselves to be applying Scrum - perhaps even most of those that do - nevertheless struggle to articulate sprint goals. They don't often recognize that the whole purpose of identifying a sprint backlog is to frame and meet such a goal, to account for the team's progress towards it, and to make any replanning transparent. For these teams a sprint backlog is merely a batch of work that is brought into progress and their goal is to complete it. So common is this perspective that it almost amounts to received wisdom...it's promulgated as being the way scrum is, and is meant to be. Is it any wonder that the likes of Kanban and Scrumban are promoted as leaner and more agile ways of working?
Of course, we can see that these teams are not applying scrum properly in the first place. By failing to understand the significance of sprint goals they are unable to leverage the opportunities provided. The team's ability to mitigate substantial business risks on cadence is impacted accordingly.
In some situations however, this may not amount to a significant loss. For example "Business As Usual" work must, by definition, consist of changes for which the associated business risks are minimal. None will be at the scale of project work. A BAU context is typified by small and repeatable changes, some or all of which might be templated. Defect fixes and changes to CMS content are par for the course in BAU delivery. Each change can follow its own journey into service and is independently releasable. No batching of this work is necessary or desirable since there is no greater goal or "coherence" to be served. A ticketed Kanban system may be sufficient for the team's purposes. Without larger business risks to frame and control, a team can focus on optimizing flow and on improving its DevOps capabilities.
Unfortunately, few "scrum" teams can articulate sprint goals, or account for their absence in terms of risk management. Unable to grasp their true purpose, many teams botch their implementation of scrum by allowing these goals to fall by the wayside. The heart of scrum is lost, and the framework is applied in an irrational way that makes a nonsense of having sprints at all.
The lesson we must draw for ourselves is brutally simple. If business risk is high, and value must be delivered in conditions of great uncertainty, then it is wise to look for goals and how they might be achieved incrementally and on cadence. If goals can be framed that address these risks, then a team may sprint towards them, and the scrum framework can be usefully applied. If risk is low enough for these goals to be of no use, then perhaps other agile approaches ought to be considered instead.
Be aware then of what you will lose, and put at risk, should your sprint goals be compromised. Scrum is not a pick-and-choose framework where components are optional. It is a systemic solution for complex problems where there is great risk and uncertainty. So ask yourself this. Is your environment really so simple that the goals which underpin scrum may serve no useful purpose?
“If you don't know where you are going, you'll end up someplace else.”
― Yogi Berra