Missed launch deadlines? You don’t have time for that. Book a free consult to learn how we can help you navigate the product development process to meet your goals.
This is the first in a two-part series. Read Part two here.
You have probably read and heard at length about how Agile methods and the Scrum framework make development sleeker, products better tailored to their users, and applications more adaptive to the market. This is all true, and can absolutely happen for your team, but a proper Scrum needs more than just stand-ups and retrospectives. Your team needs Goals.
Scrum can easily turn into a repetitive cycle of meetings and processes, especially when everyone is working on their own project and the roadmap is dictated instead of discussed. I would argue that Scrum does not work unless individual teams work on one goal at a time. If you don’t set, limit, and stay on topic with your Goal, you are working with half of a framework. It is time to stop “doing agile” wrong and to get your team on track.
So what is a Goal? How do I set them? Why do they matter? If this drives the whole Scrum framework, how do these Goals work?
What is a Goal?
Keeping the team aimed towards a specific target focuses their efforts in a certain direction. With that context, it becomes important to make those goals actionable, specific, and relevant to the product development team. To name these, we use the language of Goals.
The Scrum Guide offers two layers of these goals: Product Goal and Sprint Goal.
The Product Goal
The Product Goal is the long-term objective - the future state of the product that the cumulative sum of the backlog builds towards. It is
“… a future state of the product which can serve as a target for the Scrum Team to plan against.”
Most Product Goals should be within the six-month timeframe. Something within sight, within the known market, and achievable by the team. All of the things in the backlog should work towards this goal. Anything outside of this goal should be closely scrutinized to see if it is actually valuable and urgent enough to deviate from the central goal.
These commitments should center around outcomes for the users. Avoid “impact” related goals like “earn $1 million in sales” or “get 50,000 new users.” Instead focus on user outcomes - things like “flag potential adverse drug interactions in patient charts to reduce harm,” “help high school students apply for FAFSA,” or “identify symbiotic plant species to create more efficient gardens.” These should be high-level, user-centric, and story-based.
Looking through the Product Goal as a lens, you can evaluate the priority of the requested work. Asking questions like “Does adding a profile picture management tool contribute to my goal?” “Will geolocation make college applications easier?” or “Will (insert feature here) get us closer to (insert goal here)?” If something does not fit into the goal, get it out of your backlog.
But the Product Goal can only help winnow down the feature requests. What does this matter day to day?
The Sprint Goal
The Sprint Goal takes the high-level target and describes a measurable and actionable goal for this sprint. It is the single objective of the sprint. It encapsulates the desired outcome of the sprint’s work, with space for the team to determine how to achieve it. It fosters collaboration, enabling the team to collectively work towards a destination as opposed to working independently within the same product. This is why they need to have one goal, and not several. The Sprint Goal binds the entire sprint together; it is the hero element of every ceremony.
Sprint Goals also force the product team to follow an iterative process instead of a rigid waterfall lifecycle. Instead of setting the specific features, functionality, and design of the product a year in advance, this iterative model makes every sprint an opportunity to re-evaluate the importance of the next step. Every sprint is a chance to think about the next thing to build, its relevance to the goal, the other factors you have learned along the way, and the importance of competing factors.
Some examples could be “create a prescription list uploader,” “visualize user progress through articles,” or “create database backup systems.” These goals require team buy in, group discussion, and negotiation. The Product Owner helps set the rough goal, and the engineering team negotiates down the specifics of how that goal is achieved.
But Why Have Only One Goal?
If Sprint Goals set the theme of the whole sprint, you want a theme that can rally the whole team together. Without a shared goal, the team will be pulled in several directions and unable to focus on a single topic. Plenty of authors have written at length about the costs of context switching, and forcing the team to switch contexts every ticket, every meeting, or every pull request slows down your delivery each and every time. You also negate the benefits of having the team work together. Instead of collaborating, they simply work in proximity to one another. So rather than making minor progress in a lot of directions, use a single goal to make major progress every time in a single direction.
In part two of this series, we will take a look at how they tie every meeting together. In the meantime, take some time to put together a Product Goal to encapsulate the medium-term outcome you want to achieve for your users. From there, work with your team to put together simple, actionable, and measurable Sprint Goals.
