"If you don't know where you are going, you probably won’t get there."–Yogi Berra
The pager tones sounded at 2 a.m. "Squad 86, car accident with personal injuries on Highway 268 west of Pilot Mountain." I don’t know how much research went into deciding how loud the tones should be, but when they sound, they can wake anyone from sleep. I quickly calculated that the accident was less than a half-mile from my house. I climbed into my turn-out gear, got into my car, and off I went. I found the first patient sitting on the side of the road. Talking with him revealed another victim, somewhere on a side road. Other squad members arrived. I could hear the ambulance siren headed our way. Their goals were simple: Find the patients, stabilize their injuries, and send them to definitive care.
Similarly, software development teams need three common goals: long term, mid term, and short term. These goals focus a team and provide the glue that holds the team together. They answer the basic question "Why am I here?" Knowing why the team has been brought together provides purpose and identity. These goals are the project goal, sprint goal, and daily goal.
Project goals provide the overall direction and answer the questions "Which part of the corporate mission statement does the project I’m working on support?" and "What business goal does this completed project meet?" Time for these goals ranges from several months to years. Suppose your company has a strategic goal to increase their product offerings. After some research, the managers decide to create an application that uses a camera to track the user’s eyes and automatically move the cursor based on eye movement. The project charter should connect to the "increase product offerings" strategic goal. Using the project goals developers can connect today’s work with the company’s strategic goals. Since long term goals take months to years, we need interim goals to track how we’re doing.
Sprint goals act as the checkpoints along the project's path. These checkpoints answer the questions "How are we doing toward meeting the long-term goal?" and "Are we done yet?" Sprint goal time spans should be between two to four weeks. Having sprint goals allows the team to verify progress as they deliver working software. Additionally, these checkpoints allow the team to make corrections if they misunderstood the functionality required for the mid-term goal. An example sprint goal for the eye tracking application might be to find and activate the computer camera. The developers can check their daily activities against this goal. If they can't tie what they’re doing to the sprint goal, they should ask "Why am I doing this?"
Daily goals focus on the implementation question “Who does what, when, and where?” These tasked oriented goals have a time span of a few hours to a couple of days at most. This enables the developers to make visible progress toward the sprint goal. Problems meeting the short-term goals can bring a team together by providing an opportunity to cooperate by swarming to overcome the problem. Completing task goals indicates if the sprint goal will be met.
Hitting the sprint goal of "finding and activating the computer camera" might include:
- Query the OS for Devices
- Determine which devices are cameras
- Locate drivers for those devices
- Enable the drivers
- Turn on the camera
These tasks may be further sub-divided. Not completing these task goals puts the sprint goal in jeopardy, which in turn impacts the project goal.