7 Sprint Goal Patterns for Building Great Teams, Part One
Mar 23, 2015 by Vyacheslav Moskalenko
Menu
×
Imagine playing a video game with such incredible graphics and inspiring dynamics that, before you knew it, hours had passed. You know that at the end of the game your hero will meet a final foe, who you will eventually vanquish after a tough match-up. But after so many hours of play, you start to discover irritating aspects of the game – there aren’t any mid-level foes, side-quests, options, missions, any badges or achievements. Moreover, it says you’ve got forty hours before the end of the world, but you don’t have any sense of how far you can go with the remaining time. What would be your motivation to keep playing that game?
A well-defined software development process is just as important as proper game design. Challenging problems, exciting technologies and innovative frameworks won’t elevate your team’s motivation without sidebar elements to mark progress, like well-defined interim missions and regular feedback from clients.
The Project Manager, Scrum Master, Team Leader, or any other leadership role defining organizational practices, should really think creatively if he or she wants a truly engaging process that encourages a sense of fun, courage and creativity for developers. Ultimately, this is about motivation. If you make this a personal goal, I know you will find what you need to make it happen for your team.
The “Sprint Goal” is a practice that originated in Scrum. After more than five years of personal experience using Scrum, I learned that a team’s Sprint Goal has to sound pragmatic.
Sprint Goal: Complete Five User Stories and Fix All Production Bugs
I used this text template many times, with different Scrum teams.
In some cases, I said to my team, “We have almost completed all our objectives, so let’s consider this sprint a successful one.” In other cases, I stressed that we had failed to reach our objectives. I was not completely clear and transparent to the team.
I used this practice not as a process element, but mainly as a tool to deliberately push teams to work harder. After some time, I revisited all my approaches and their resulting errors. I found that one of my main mistakes was introducing and supporting practices with the wrong intention. If my goal is to strengthen a team’s sense of fun, courage, open-mindedness and self-organization, then the nature of the Sprint Goal should change completely.
There is no recipe book that explains how to increase a development team’s motivation in a systematic way. Team leaders need to be creative and innovative if they want to build a great team. First, let’s reconsider Sprint Goal mechanics and aesthetics. Going back to our previous analogy, why do we like games?
One reason is because they have a non-biased mechanism that results in a fair score at the end of the mission. For the development process it’s hardly possible to invent a calculator that will generate a fair score. We have to rely on someone’s opinion…the Scrum Master’s? Well, I was once in those shoes, and it just didn’t work. What about the Product Owner? Maybe – however, the Product Owner’s opinion can also be biased.
A good option is to have the development team make a self-assessment during the sprint retrospective meeting. Another option is to ask your stakeholders for their opinions if they are present at the sprint review meeting. The benefit of having a stakeholder in on a demo session allows you to ask for more detailed feedback. As a part of the feedback process, let that person rate you – using stars, numbers, sticks, apples, monkeys, whatever. Based on the completeness of the achieved Sprint Goal, you can generate a score based on satisfaction level, gained business value, and other measures. You can use scores, bonus points (for when the team was able to exceed the value set by the initial Sprint Goal, for example), energy levels, badges and other ways to summarize the team’s results. Avoid the basic “Sprint Fail/Sprint Success” dichotomy.
Let’s explore patterns for setting the Sprint Goal so that it can work together with a qualitative assessment. We have to first define some principles and rules in order to set up a good Sprint Goal:
The primary purpose of any development team is to deliver valuable software and technology aligned with their customer’s expectations. Building a great team is a higher purpose with a lot of space for improvement and experimentation.
First we need to define the criteria for great teams. In Agile Development, this kind of criteria can be inspired by the Agile Manifesto or any other relevant Agile disciplines – for instance, a Scrum Team has to share the same Scrum values. But when your team doesn’t meet those criteria, I suggest fixing it by wrapping the primary purpose around a higher purpose. The retrospective outcomes from meetings can be a good source of meaningful “higher purpose” goals. Sure this works for existing development teams, but what if the development team was just formed? Then, it’s the perfect time to set up a higher purpose and nurture good habits from the very beginning.
Here’s an example: The development team is at the beginning of a project with no experience in Agile. If they can get the job done and immediately receive their first taste of positive feedback from their stakeholders, it will create a positive reinforcement loop. Delivering valuable outcomes can be a significant first achievement for building up a great team.
Sprint Goal: Demonstrate Added Value for the Customer in the Very First Sprint
The higher purpose of this goal is to instill a value-driven mindset for the development team. The team is expected to demonstrate a valuable functionality over increments for the customer at the end of each sprint. We have just wrapped a primary purpose (software development) in a higher purpose (focus on customer value, time boxing, etc.) Now let’s make this mission even more advanced:
Sprint Goal: Release a Valuable Increment to the Customer within One Sprint
The development team has learned that, at the end of iteration, they should be able to demonstrate at least a bit of the expected value and functionality. The higher purpose here is to develop the team’s habit of getting things DONE. This can be a challenging mission for the team: What if they fail to achieve it? How do they set up another mission with similar objectives while making sure it doesn’t just repeat itself?
Metaphors can be used when the development team needs an inspirational message to unlock motivation. Here are examples of situations where this is helpful:
Sprint Goal: An Apple Tree Bearing Fruit Has Deep Roots, but Still Produces at Least One Apple in the First Year
The primary purpose of the tree is to bear apples. However, we respect the fact that a young tree should develop a root system first in order to become truly “fruitful.” The metaphor’s meaning for the team might need to be focused on architecture and technology first, but in the meantime the team can produce at least one apple nonetheless, as more will follow.
With this, we reinforce a value-driven mindset in a tough and technologically challenging, non-trivial product. It is hardly possible to develop a great team without autonomy and giving the team trust and respect. So the idea is to give the development team a second wind by using inspiration, particularly when they have failed to meet higher purpose goals and expectations.
Sprint Goal: The Bravest Warriors Conquer the Last and Most Complex Part of the Land
Imagine a situation where the development team is working to complete an epic functional item for months because requirements keep changing (or for some other reason). You want to inspire them to get to the DONE stage, and come up with a saying such as, “Brave developers are completing the latest piece of the epic financial report.” If I were a developer I would be annoyed with this message – but by using the abstract metaphor above, it gets the message across. It’s saying the same thing, but in a different way, and encourages performance.
Sprint Goal: Skillful Hairdressers Create a Sexy New Look
Stakeholders want to redesign the look and feel of their software, while you want to strengthen the team’s motivation for the task. As in the previous example, without using a metaphor, the stated goal might sound like “Skillful Developers Create Sexy UI,” which is awkward and discouraging. Good Sprint Goals should be wrapped in metaphors that are inspiring and fun to complete. Do stakeholders need to clean up their software from defects and bugs? Think about this:
Sprint Goal: Clean the City of Critters
Give it up for good, old classic movies. I was amazed how encouraging it can be to fix bugs with blasters and beam guns, but the development team may want go even further and envision the next goal like this:
Sprint Goal: Build a Strong Electromagnetic Fence to Defend the City from Critters
In some Agile methodologies like Scrum, the development team is allowed to craft a Sprint Goal. In this case it’s reasonable that the team wants to improve software quality by building a fence. However, we have to ensure that there’s still a releasable value.
A common way to feed requirements for Agile development teams is to select a couple of user stories from the top of the list with well-understood acceptance criteria. In the planning meeting, the development team creates a plan to deliver those items and makes sure this plan looks fine to the Product Owner. The team, together with the Product Owner, crafts a Sprint Goal, “Implementing Risk Factors Functionality,” and sets it for the next sprint. At the end of the sprint, the development team shares user stories according to each acceptance criteria. However, the Product Owner and stakeholders are not happy that, in certain cases, the risk factors were applied with mistakes.
From a requirements standpoint, everything was fine. The Product Owner thought that it was obvious to the development team that the most desired component was reporting, but the team was more focused on editing functionality. When we need the development team to focus on the most desired scenario, test or component, it needs to be reflected in the Sprint Goal. In this case, a better Sprint Goal might be:
Sprint Goal: Show Risk Factors Applied in the Annual Risk Financial Report
The user stories and acceptance criteria don’t change, but the delivery plan will vary depending on how the Sprint Goal is crafted. The bottom line here is that great development teams have a focus aligned to the customer’s most desired outcomes.
I continually observe situations where the same component becomes the most important functionality, which is key to project success. You will benefit if you can recognize what that key component is.
In the next part, we will continue exploring Sprint Goal patterns, so stay in touch.
To be continued…
