百事广告下架后就没了声音，有两个广告人急了

SMART goals vs. OKRs

When teams use SMART goals, they first identify the goal and then use the SMART acronym to define the goal: Specific, Measurable, Achievable, Relevant and Time-bound. This moves the goal from a simple vision to something concrete that is either done or not after a designated time span.

OKRs start with a business objective that appears in real life. The key result is satisfied if the business objective is satisfied. Managers and their teams can measure this in terms of customers on the website, sales numbers, reduced sales cycles and so on.

A SMART approach ensures a goal exists with a deadline and standard of measure. SMART goals are often associated with individual career progression and expressed annually, such as finishing a college degree or completing a project by a certain date.

OKRs are more likely to be visited monthly and revised quarterly. They start with an introduction about what the company wants to accomplish. They then become a conversation about what to measure and how to define success called a catchball approach. OKRs are tied to high-level goals of the business.

"Team members find more value in their work when they understand how what we do solves business problems," said Julie Klausing, chief consultant at Spark Management Group. "This understanding of why my work matters also leads to more excitement and ultimately more engagement by the team. When they feel personally invested in business success, their contribution to that success tends to increase."

OKRs vs. SMART goals on a software team

The best way to understand OKRs and SMART goals is to see them in action.

An example of an unconstructive goal is for a team to accomplish 50 points of work in the next sprint or 600 points over the next three months. A team lead or Scrum master could track the number of story points, which measure the complexity of the proposed software, delivered on a chart so the team members know if they are accomplishing their goal.

One problem with this method is that the team could create low-quality software that is full of bugs; a second goal might be necessary to cap bugs at a certain number.

Another problem is the story points themselves. Story points lack construct validity. They aren't a scientific measure and instead are a rough guess at the complexity of the work. Typically, a team will attempt to size the micro-features, called stories. Once a measure of points becomes a target, the team is strongly incentivized to turn everything into many points. Team members who both estimate and perform the work under pressure to earn more points can simply increase their estimates. This will yield charts that show improvement, but it doesn't deliver more software.

Many teams don't have the information they need to develop quality OKRs.

An alternative is to count the number of stories. This encourages a team to split the work into smaller parts. Small stories have benefits, such as less ambiguity, less uncertainty, fewer unexpected combinations and shorter wait times. Counting stories tends to provide better outcomes than story points and reduces some of the time spent estimating.

Instead of a points approach, a SMART approach lists specific goals for the team to accomplish in three months, such as to integrate with the tax product or enable the salesforce to submit orders on mobile devices. The development team can discuss if those goals are relevant and achievable. That work requires more planning than a points approach, but these details should already be on the product roadmap.

To transform those SMART goals into OKRs, the features must tie to business outcomes. For example, having a mobile feature should benefit the staff in a measurable way, such as a 5% increase in sales within three months after launch. Likewise, the purpose of tax product integration might be to either improve customer retention or enable cross-selling of product lists. Both have a bottom-line outcome that can be expressed as a key result.

Many teams don't have the information they need to develop quality OKRs. They have no way to measure success in terms of a particular goal's meaning to the business. They then settle for points-per-sprint. If your team doesn't understand the results of its work on the business, initiate conversations to make it clear.

Getting started

Goals can be either bottom-up or top-down. If your goals are top-down, use OKRs to make sure you understand the goal and then a SMART approach to detail the goal and know if it is accomplished. Driving goals from the bottom up can be challenging but rewarding.

Organizations that lack vision often struggle with a top-down approach. Without direction, goals are more likely to be vague. If this is the case, a bottom-up approach can outline steps to define goals:

• Start with vague goals and use a SMART approach to make them more robust and detailed.
• Set a small period -- for example, a month -- to produce a published list of SMART goals.
• Assess what leadership needs to accomplish those goals and how the goals benefit the organization.
• Use catchball to turn those goals into OKRs that benefit the business.

SMART goals are a good place to start with a bottom-up approach, but don't stop there.