Pick a sprint type. Get 5 fill-in-the-blank goal templates designed around outcomes, not deliverables.
Tip: Pick a type to see guidance.
Loading…
SprintFlint keeps the sprint goal visible on every issue and tracks goal-hit-rate sprint over sprint. The goal stops being a meeting artefact and starts being a working signal.
Start FreeIt names a user or business outcome, not a deliverable. "Ship the dashboard" is a deliverable; "30% of returning users see and engage with the new dashboard" is a goal. Outcomes survive scope changes; deliverables don't.
Technically yes, in practice no. Two goals means no goal — the team has nothing to optimise toward. If you have two priorities, pick one as the sprint goal and one as a "supporting" output. The goal is the conversation-anchor when something has to give.
Specific enough that you can answer "did we hit it?" with yes/no/partial. Vague goals ("improve quality", "ship features") give you no signal. Specific goals make retros productive.
The PM proposes it; the team commits to it. The PM brings outcome thinking ("what would matter to users / stakeholders this sprint?"); the team validates feasibility. If the team can't commit, the goal is too ambitious — re-scope.
This means scope or priority changed. Either reframe the goal (rare, only if a real strategic shift) or accept that the sprint is now goal-less and use what you learn in retro. Don't pretend the goal still applies — that just trains the team to ignore goals.
Sprint goal is team-wide for the whole sprint; acceptance criteria are per-ticket. Goal: "30% of users complete onboarding." Acceptance criteria for one ticket: "user can resume onboarding from any step." Both matter; they're different layers.
Read 12 real-team sprint-goal examples, or try SprintFlint free for 300 tickets.