Writing SMART goals: The complete guide with examples and templates

A SMART goal for a software team is a delivery outcome written to be Specific, Measurable, Achievable, Relevant, and Time-bound – and, in a Jira-based org, one that maps to an issue, an epic, or a Structure hierarchy where progress is visible without a status meeting. The framework was introduced by management consultant George T. Doran in the November 1981 issue of Management Review and has since become the default goal-writing rubric across engineering, product, and PMO functions.

SMART works best for software teams when each letter anchors in the tools the team already uses: An epic link for Specific, a burn-down or cycle-time metric for Measurable, a capacity model for Achievable, a portfolio theme for Relevant, and a sprint or PI boundary for Time-bound. Treat it as a standing diagnostic – something you rerun against the goal every few weeks.

Where SMART goals came from

Doran built the checklist as a reject function for Peter Drucker's Management by Objectives approach, which produced too many un-actionable goals like "improve morale." His original 1981 article laid out the five-letter test in a page and a half.

Two decades later, organizational psychologists Edwin Locke and Gary Latham gave the filter a research base – their 2002 synthesis in American Psychologist reviewed thirty years of goal-setting studies and found specific, difficult goals consistently outperformed vague or easy ones. That's why the checklist outlasted its replacements. Every one still borrows the same demand: Name the number, name the date, name the owner.

What are SMART goals in software development?

SMART goals in software development are commitments – usually at the sprint, quarter, or program-increment level – written against a fixed structure so ambiguity is squeezed out before work starts.

• Specific. One outcome, one owner, one scope. "Improve checkout" is too vague. "Reduce the p95 latency of the /checkout endpoint from 900ms to under 400ms" is the version you can score. A specific-sounding goal can still hide a missing owner.

• Measurable. A number pulled from a source the team already trusts – a dashboard, an APM tool, a finance report. When the number comes from a status field someone types in, the goal drifts before the deadline.

• Achievable. Grounded in the team's real headcount, budget, and calendar. Two ways this goes wrong: A target set so low that hitting it proves the team can breathe, or a target lifted from a competitor's announcement without checking whether the team on the hook can deliver it.

• Relevant. Every goal ties to a product theme or strategic bet a leader has already approved for this quarter. Relevance is the letter teams fake most. The goal reads as strategic in the deck; the leader who owns this quarter's priorities has never seen it. Portfolio prioritization exists as a discipline because team-level work and portfolio-level bets lose their connection here first.

• Time-bound. One fixed date. "By Q3" invites drift. "By September 30" fixes the target on the calendar. Pair the goal with milestone tracking so the deadline lives against the tickets feeding it.

Why SMART goals matter for engineering teams

Engineering goals need a scoreboard to survive the quarter. "Improve platform reliability" offers every team a way to claim they moved the needle. A SMART version – "cut Sev-2 incident count from 14 to fewer than 6 in Q3" – has a scoreboard, and the scoreboard changes behavior long before the deadline.

Tempo's 2026 State of SPM Report found a roughly 12-point ROI gap between organizations with integrated portfolio review processes and those without. Unreviewed goals surface repeatedly as the reason. Call the alternative goal theater – a goal that passes the SMART checklist, gets its slide in the planning deck, and then goes silent because the mechanism to catch drift was never built. SMART is meant to prevent goal theater, and every team drifts into it by default. OTP Bank hit exactly this problem across its portfolio and rebuilt around a shared quarterly review; their case study walks through how they did it.

Where SMART breaks down in software:

• Achievable becomes sandbagging. Punish a team when a goal falls short and they learn to write goals that guarantee wins. Treat shortfalls as diagnostic data – what changed, what got in the way – and the incentive to sandbag drops.

• Measurable becomes vanity. "Ship 40 stories" tracks ticket throughput and stays silent on whether any of them delivered value. Prefer outcome metrics (latency, adoption, revenue-per-release) over activity metrics.

• Relevant gets skipped. Engineering teams often write SMART goals in isolation from product strategy. The result is a well-executed goal disconnected from the strategy it was supposed to serve.

• Time-bound conflicts with agile. Sprint-length goals encourage local optimization; quarter-length goals get stale. Pair a quarterly outcome goal with sprint-level leading indicators – let each sprint goal name its slice of the quarterly target instead of drifting into its own scope. The sprint sets the pace. The SMART goal names the destination.

• Dependencies stay unnamed. A goal riding on another team's roadmap, a vendor's release date, or a budget approval still writes as a clean SMART sentence. The first missed handoff ends it, and the ticket stays open long past the readout.

• Shared goal, single owner by accident. Whoever presents the goal in the planning meeting becomes its owner by default, even when three other teams have to deliver pieces of it. That person answers for outcomes the team only partly controls.

SMART goals examples for software teams

The examples below use realistic Jira and delivery-tool vocabulary.

1. Platform reliability (SRE / platform team)

Reduce p95 API latency on /orders from 820ms to under 350ms by September 30, 2026, measured in Datadog, without regressing error rate above 0.1%.

• Specific: One endpoint, one metric.

• Measurable: 350ms threshold.

• Achievable: Prior work reduced /cart similarly in one quarter (this is aggressive – >2x reduction typically implies a rewrite of the hot path).

• Relevant: Tied to the "checkout conversion" product theme.

• Time-bound: Hard date, not "Q3."

2. Delivery predictability (scrum team)

Increase sprint-goal hit rate from 62% to 85% across the next six sprints, recorded in the sprint retrospective, with no more than 15% carry-over story points per sprint.

Sprint-goal hit is a subjective yes/no the Scrum Master records at the end of each sprint. Jira's native Sprint Report shows commits versus completions; the goal itself lives in the retro notes. The dual condition holds the line – teams game hit rate by shrinking sprint goals until they trivially close.

3. Developer experience (internal platform)

Cut median CI pipeline time on the monorepo from 22 minutes to under 12 minutes by September 30, 2026, measured on the main branch, without increasing infra cost per build by more than 10%.

A ~45% reduction is aggressive but achievable with test parallelization and better cache reuse; anything steeper usually implies a build-system rewrite.

4. Product delivery (feature team)

Ship the self-serve billing portal to 100% of SMB customers by November 15, 2026, with less than a 2% support-ticket volume increase in the four weeks post-launch.

5. Technical debt (staff engineer goal)

Remove all references to the deprecated v1/auth client from 34 downstream services by end of Q2 2026, verified by a zero-hit repo search and a passing dependency audit.

6. Team growth (engineering manager)

Onboard four new backend engineers by mid-Q3 2026 with each reaching solo on-call rotation within 90 days, measured against a documented onboarding checklist.

How to write SMART goals in Jira

Most teams stall when the SMART goal has to leave the planning doc and live inside Jira. Here's a working pattern for that.

1. Create the goal as a Jira issue type at the top of your hierarchy. In Jira Software Premium, use the built-in Initiative issue type from Advanced Roadmaps. Otherwise, create a custom Goal issue type. (Note: this is different from Atlassian's separate Goals surface, which lives outside standard issue configuration and rejects arbitrary custom fields.) In Structure, model the goal as the ancestor via a generator; in Advanced Roadmaps or Jira Align, as the direct parent.

2. Encode the metric in custom fields on that issue. Add Target Metric, Baseline, and Deadline. The goal becomes a data object – the Measurable and Time-bound letters are queryable rather than buried in a Confluence page.

3. Link every contributing epic to the goal issue. If an epic can't be linked, it's either the wrong epic or the wrong goal. Either finding is useful.

4. Build a JQL saved filter for the goal. If you're using Advanced Roadmaps hierarchy, parent = GOAL-123 AND statusCategory != Done gives you the standing check-in view. On the Atlassian Goals surface, Goals = GOAL-123 does the same job. One filter, every check-in.

5. Overlay time and cost. Pair the goal with time tracking for logged effort or Tempo Capacity Planner for planned capacity, so Achievable rests on the calendar hours available after meetings, on-call, and support load. Teams underestimate goal cost by comparing it to velocity. Velocity ignores what the calendar has already booked.

6. Report against it on one dashboard the team already opens daily. Custom Charts and EazyBI both handle metric trend, epic completion, and burn-up in a single view, though EazyBI is an MDX exercise more than a drag-and-drop setup. Put the goal somewhere the team sees it every morning.

That's how SMART holds up – as something the team runs against every morning.

A SMART goals template

Copy this into your Goal issue template or your quarterly planning doc.

Goal statement: [Verb] the [metric] from [baseline] to [target] by [date], measured against [source of truth]. Baseline: [current value / date measured] Target: [threshold or condition to be met] Metric source: [dashboard / query / report location] Deadline: [YYYY-MM-DD or sprint / PI boundary] Owner: [single named person] Parent OKR / theme: [link] Contributing epics: [Jira links] Guardrails: [what must stay stable – e.g. cost, error rate, SLA] Check-in cadence: [weekly / biweekly / monthly]

Most templates skip Guardrails. Guardrails make the Achievable claim honest. Any metric moves if you're willing to break something else, so name what has to stay stable.

SMART goals in adjacent functions

Engineering goals live inside a chain of upstream and downstream commitments. What's achievable depends on what those functions have already promised. Same structure (verb, baseline, target, date, source of truth) applied where engineering has real dependencies:

SMART goals vs OKRs vs KPIs: which one do you use?

OKRs come up in nearly every planning meeting as the framework meant to make SMART goals obsolete. The reputation is deserved – Google and Intel built cultures around OKRs, a history John Doerr's Measure What Matters documents in detail. SMART goals, OKRs, and KPIs do different jobs at different time horizons.

A SMART goal is the unit. An OKR is often several SMART goals nested under a shared objective. Drop SMART for OKRs alone and alignment survives while ownership scatters – an objective can cascade through five teams with only diffuse accountability for a single number. A KPI keeps running after both close and tells you whether the process stayed healthy.

The decision in practice: Use a SMART goal when one team needs to commit to a single measurable outcome for a quarter or a project. Use an OKR when several teams need to align under one strategic objective and one number can't capture it. Use a KPI when you're monitoring an ongoing process that runs indefinitely – support response time, uptime, churn – and need a standing health check. Most portfolios run all three at once. Performance measurement and analytics tools track all three side by side, so a team keeps whichever framework loses the internal argument. If the argument turns definitional, OKR vs KPI is the reference to send around before the next meeting.

How to track and measure SMART goals

Every goal needs a review cadence matched to its length:

• Weekly for a goal running four weeks or less

• Biweekly for a quarter-length goal

• Monthly for anything spanning two quarters or more

A goal without a review cadence becomes moribund on a slide, forgotten before the quarter ends.

For outcome verification, prefer sources the team doesn't control end-to-end – an APM tool, an analytics warehouse, a finance system – over a value someone types into a status field. Self-reported completion is why goals stay green until the readout deck flips them red.

For progress monitoring, build one view that answers three questions on a single screen:

1. Where is the metric today, versus baseline, versus target?

2. Which epics are contributing, and what percentage of their stories are done?

3. How much team capacity has been spent against the goal so far?

If any of those three questions requires a spreadsheet, the update lags a week behind reality.

An initiative tracker catches what a standing review alone overlooks once you place a goal beside it. Tracked next to the actual tickets, a SMART goal exposes the plan-vs-delivery mismatch the moment someone looks. Add time tracking and you see whether the hours logged against the goal match the hours the plan assumed. The moment those diverge, the achievable promise is already broken.

A short post-mortem when a goal closes – wins and losses alike – turns that shortfall into a pattern the team can act on next quarter. Goal theater ends when the mechanism to catch drift is built into the workflow, not tacked onto it after the readout.