Welldefined software development process is 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 start thinking 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 Traditional Way
“Sprint Goal” is a practice that originated in Scrum. After more than five years of personal experience using Scrum, I thought that a team’s 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 almost completed all objectives, so let’s consider this sprint a successful one”. In other cases I stressed that we have 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 a team 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 Sprint Goal should change completely.
The Creative Way
There is no book with recipes that explains how to increase a development team’s motivation in a systematic way. I need to be more creative and innovative if I want to build a great team. First, let’s reconsider Sprint Goal mechanics and aesthetics. 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 in those shoes, and it just didn’t work. What about the Product Owner? Maybe – however, the Product Owner’s opinion also can be biased . A good option is when the Development team is making a self-assessment during the Sprint Retrospective meeting. Another option is to ask stakeholders’ opinion 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, he can generate a score based on satisfaction level, gained business value, and other measures. You can use scores, bonus points (for when 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.
Sprint Goal Patterns
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 a good Sprint Goal:
- The Sprint Goal should encourage coherent function or functionality.
- The Product Owner should be in agreement with Development Team and should be able to improve the requirements scope so that it allows the team to earn points for more than just the completed mission (Sprint Goal). The Dev Team works to improve technology and teamwork to earn as many points as possible.
- The Sprint Goal, or mission objective, is not repeated over the course of many sprints. Each sprint should have its own unique mission.
- The Sprint Goal (mission) may consist of several User Stories (quests). We cannot tally points for the quest if it’s not fully complete according to the Definition of Done .
- Setting the Sprint Goal is the Product Owner’s responsibility, but crafting it is a shared responsibility of the Scrum Team, including PO.
- The Sprint Goal encourages initiative in multiple areas – teamwork, technology, quality, and mindset. However, while improving those areas, make sure that you are creating a potentially releasable increment by the end of the Sprint.
- The Sprint Goal is the prototype for future sprint outcomes. Make it beautiful and attractive.
Pattern #1 - Higher Purpose
The primary purpose of any Development Team is to deliver valuable software and technology aligned with customer expectations. Building a great team is a higher purpose with a lot of space for improvement and experimentation. First we need to define criteria for great teams. In Agile Development such criteria can be inspired by the Agile Manifesto or any other relevant Agile discipline – for instance, a Scrum Team has to share Scrum values.
When your team doesn’t meet those criteria I would suggest fixing it by wrapping the primary purpose around a higher purpose. Retrospective meeting outcomes can be a good source of meaningful ‘higher purpose’ goals. 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.
Let’s use 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 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 in 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 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, that doesn’t just repeat itself?
Pattern #2 – Metaphor
Metaphors can be used when development team needs an inspirational message to unlock motivation. Examples of situations where this is helpful:
- The team failed to achieve the Sprint Goal in the previous iteration
- Conflicts inside the team are blocking progress
- Some functionality or requirements have been in progress for a long time
- There aren’t any interesting or challenging objectives to work on - for instance redesign, support or bug fixing
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. 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 without 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 some other reason). You want to inspire them to get to 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. You want to strengthen the team’s motivation for the task. As in the previous example, without using 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. Stakeholders want 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.
Pattern #3 – Inflate
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. The development team in the planning meeting creates a plan to deliver those items and 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 demonstrates user stories according to 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 thing or component becomes the most important functionality, which is key to project success. You will benefit if you can recognize that key component.
In the next part we will continue exploring Sprint Goal patterns. Stay in touch. To be continued…