Step 4: Start With the Highest Impact Goals
Step 4 begins at your team’s next Sprint Planning event. At the very beginning of the event, the team is supposed to work out the “WHY” for the Sprint. This is where your goal list comes in. Start talking through the goals with the team and get a decision on which goals will be addressed in the sprint being planned. Don’t plan too many goals into your sprint. In fact, since many goals take more time than a single sprint to achieve, the team will probably have to break the goals they want to include in the sprint into smaller pieces (like Story Slicing).
A great example of this is the first order impact goal: “By June 30, complete the high value features for Product A Release 2.” Your team isn’t likely to finish all of the necessary work in a single sprint. What could they focus on? What feature or group of features could be done this sprint?
Likewise, you might need to step into a goal: “By March 30, reduce new defects found after integration testing to 3 per sprint.” Perhaps the team’s current new defect count is 15. I don’t think going from 15 to 3 in one sprint is achievable. How about 12 instead?
Note: we use the term “information hold” in the following paragraphs. An “information hold” is what my teams often call an instance where a Product Backlog Item is blocked more than one day for information the team does not currently have.
Similarly, the goal “By April 20, improve Sprint Planning so that the team has no more than one information hold during the Sprint” might not be achievable in one sprint. If the team is currently at 10 information holds, perhaps the team should shoot for 8 in the sprint they are planning?
Remember, you don’t want more than 3 goals in a single sprint. Just like the adage about too many “top” priorities (“if everything is a top priority, nothing is”), too many goals can have the same problem. So, at this point, your team might have this list:
By the end of the sprint,
- complete user account definition as required in release 2 (first order impact goal reduce to a group of functions – the ability to properly define a user account)
- reduce new defects found after integration testing to 12 per sprint.
- reduce information holds during the sprint to 8 through more in-depth sprint planning.
This, by the way, is called a SPRINT GOAL.
You are ready for Step 5.
Step 5: Determine metrics
Ah! There’s that word again: metrics. Except now we’re ready for them.
Look at the sprint goal from earlier. The necessary metrics are now straightforward.
- Complete user account definition – measured by completing all of the product backlog items in the sprint that help complete the user account definition.
- Reduce new defects – measured as the defects found in integration testing; the goal for this sprint is twelve.
- Reduce information holds – measures as the number of times during the sprint that a product backlog item is blocked for more than a day; the goal for this sprint is eight.
This is how the metrics become obvious once the goals are understood. Also, this is the proper use of metrics — not created for their own sake, but as a way of measuring the achievement (or maintaining) of a goal.
During sprint planning, your team should discuss 1) which product backlog items will achieve the user account definition, 2) what they need to do differently to reduce defects in integration testing, and 3) what they need to do to reduce information holds during the sprint.
Step 6: Inspect and Adapt
During the sprint retrospective, your team can review goal attainment, discuss what they could have done better, and even decide which goals to include in the next sprint.
Some goals will carry forward – for example, the team wants to reduce information holds to one; they reduced it to eight in the previous sprint. So, they might decide to repeat the same goal in the next sprint with a lower measure (five, this time, instead of eight).
Oh, By the Way…
Yes, the goals and metrics being used by a team SHOULD be reviewed by management. After all, a manager has as much (sometimes, more) at stake as the team in achieving goals. When the metrics are properly constructed (as I’ve described in this post), any good manager should be able to see what she and her employees can do to help the team improve.
If you’re a manager or leader and aren’t sure how to handle a discussion with their teams about improving on their goals, check out The Leadership Edge.
Once a goal is achieved, the team might still want to measure for it (for example, continuing to measure information holds during the sprint in case it increases again), but they needn’t keep repeating the goal once it’s achieved.
New goals will be added on a regular basis. Just make sure that the goal is properly ordered within your goal list. Old or outdated goals get removed.
What About Velocity (Productivity) Metrics?
Measuring velocity is one of the most worthless things that companies do today. Velocity is not something that a team can directly impact – teams can’t go faster just because we ask them to. Velocity is affected indirectly as best (that is, the team does something that causes something else to happen that causes velocity to improve). Velocity can be useful for answering questions like “how much work can we load this sprint?” or “where in the product backlog where we probably be in five sprints?” It has been, in fact, recommended, that teams understand their current velocity for planning and prediction purposes.
However, when management measures velocity as a goal in itself, it does nothing but place unwarranted and unhelpful stress on the team. My recommendation: get rid of all productivity metrics. Instead, if your team wants to improve their outcomes, have them discuss things they can actually DO that will, indirectly, improve productivity.
Instead of useless goals like: “improve productivity by 10% over the next three sprints,” try “reduce information holds by 50% over the next three sprints” or “reduce daily work-in-progress,” things that will actually reduce waste, resulting in an improvement in productivity.
When faced with a useless goal like “improve productivity by 10%,” teams often resort to either packing more into the Sprint than they know they can do or padding their estimates so that it appears like they are doing more.
Agree Upon Goals, Let the Metrics Emerge
Metrics are an end result of a goal-based discussion. They aren’t an end in themselves. When management wants to talk about metrics, you make the discussion about goals. For example, imagine someone says to a Scrum team:
“I need you to improve productivity by 5% within two months.”
The best response is, “can you tell us what it is you are trying to achieve with the extra 5%?” In other words, a 5% increase in productivity is rather arbitrary. What do they really want?
Perhaps they tell you that they need “Release 2.1” to be done on-time. If so, they’ve really missed the mark. Getting a project done on time is more about building the right things, not building everything faster. Instead of a productivity goal, focus on a value-based goal.
Perhaps they tell you that they believe your team is dragging their feet (sometimes called “sand-bagging,” wasting time, etc.). Your next move is to ask, “why do you feel that way?” Then you can address reality instead of a perception.
Productivity as an end in itself is rarely a worthwhile goal. The best goals do one of three things:
- improve capability,
- improve value, or
- reduce waste.
If your goals aren’t doing one of those things, I’d recommend rethinking them.
Once you’ve got the goals figured out, the metrics emerge from the goals and MAKE SENSE!
Tell us what you think about this blog post, tell us about your team’s goals, and definitely share the most ridiculous metrics you’ve encountered.
If you appreciate the value of this blog post, we recommend you take a look at Artisan Agility’s new training system, “The Leadership Edge,” where we discuss team goals and hundreds more useful tips and skills you can use for your teams and your entire organization.