9 min read • Guide 739 of 877
Sprint Goal Best Practices
A sprint goal unifies the team around a common purpose. GitScrum helps teams define, track, and achieve sprint goals with focused planning and progress visibility.
Purpose of Sprint Goals
Why Sprint Goals Matter
SPRINT GOAL VALUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WITHOUT A SPRINT GOAL: │
│ • Team is just completing random tasks │
│ • No unifying purpose │
│ • Hard to prioritize when things change │
│ • "Successful sprint" is unclear │
│ • Demo is just a list of things done │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ WITH A SPRINT GOAL: │
│ • Team aligned on what matters │
│ • Clear priority when trade-offs needed │
│ • Success is measurable │
│ • Demo tells a coherent story │
│ • Team motivated by shared objective │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ THE GOAL GUIDES DECISIONS: │
│ │
│ "Should we work on this bug or that feature?" │
│ → Which one helps achieve the sprint goal? │
│ │
│ "We can't finish everything - what do we cut?" │
│ → Keep what's essential for the sprint goal │
│ │
│ "Stakeholder wants this added mid-sprint" │
│ → Does it align with or derail the sprint goal? │
└─────────────────────────────────────────────────────────────┘
What Makes a Good Goal
SPRINT GOAL CRITERIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ GOOD SPRINT GOALS: │
│ │
│ OUTCOME-FOCUSED: │
│ "Users can complete checkout with saved cards" │
│ → Describes what users can do │
│ │
│ MEASURABLE: │
│ "Reduce login time to under 2 seconds" │
│ → Clear success criteria │
│ │
│ VALUABLE: │
│ "Remove blockers for partner integration" │
│ → Unlocks business value │
│ │
│ ACHIEVABLE: │
│ "Ship payment MVP to beta users" │
│ → Realistic for the sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ BAD SPRINT GOALS: │
│ │
│ TOO VAGUE: │
│ "Work on payments" │
│ → What specifically? How do we know we succeeded? │
│ │
│ TASK LIST: │
│ "Complete TASK-123, TASK-124, TASK-125" │
│ → That's a sprint backlog, not a goal │
│ │
│ TOO AMBITIOUS: │
│ "Launch entire new product" │
│ → Not achievable in one sprint │
│ │
│ NO VALUE: │
│ "Refactor the codebase" │
│ → Why? What's the outcome? │
└─────────────────────────────────────────────────────────────┘
Crafting Sprint Goals
Goal Format
SPRINT GOAL TEMPLATES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMAT 1: USER OUTCOME │
│ "[Users] can [do something valuable]" │
│ │
│ Examples: │
│ • "Users can export reports to PDF" │
│ • "Admins can manage team permissions" │
│ • "Customers can track orders in real-time" │
│ │
│ FORMAT 2: BUSINESS OUTCOME │
│ "[Enable/Achieve] [business objective]" │
│ │
│ Examples: │
│ • "Enable mobile app beta launch" │
│ • "Unblock partner API integration" │
│ • "Complete security audit requirements" │
│ │
│ FORMAT 3: TECHNICAL OUTCOME │
│ "[Improve/Reduce/Increase] [metric]" │
│ │
│ Examples: │
│ • "Reduce page load time below 2 seconds" │
│ • "Achieve 95% test coverage on payment module" │
│ • "Zero critical vulnerabilities in security scan" │
│ │
│ GUIDELINES: │
│ • One sentence │
│ • Active voice │
│ • No jargon │
│ • A stakeholder should understand it │
└─────────────────────────────────────────────────────────────┘
Sprint Planning Process
DEFINING THE GOAL IN PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STEP 1: PRODUCT OWNER PROPOSES (5 min) │
│ PO shares priority and suggests goal │
│ │
│ "Based on our roadmap, I'd like the goal to be: │
│ 'Users can complete checkout with Apple Pay'" │
│ │
│ STEP 2: TEAM DISCUSSES (10 min) │
│ Team asks questions and assesses feasibility │
│ │
│ "Is that achievable with our current velocity?" │
│ "What's the minimum for that to be true?" │
│ "Are there dependencies we need to consider?" │
│ │
│ STEP 3: REFINE IF NEEDED │
│ Adjust based on discussion │
│ │
│ "Let's scope to: 'Users can complete checkout │
│ with Apple Pay on the web app'" │
│ │
│ STEP 4: TEAM COMMITS │
│ Explicit agreement │
│ │
│ "Does everyone commit to this sprint goal?" │
│ → All: "Yes" │
│ │
│ STEP 5: WRITE IT DOWN │
│ Display prominently │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint 24 Goal: ││
│ │ "Users can complete checkout with Apple Pay on web" ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Using Sprint Goals
Daily Reference
SPRINT GOAL IN DAILY WORK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IN GITSCRUM: │
│ Sprint goal displayed at top of board │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint 24: Users can complete checkout with Apple Pay ││
│ │ Progress: 6/12 stories done | 5 days remaining ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN STANDUP: │
│ Reference goal when discussing progress │
│ │
│ "What I'm doing today moves us toward the goal because..." │
│ │
│ "I'm blocked on X, which affects the sprint goal" │
│ │
│ IN PRIORITIZATION: │
│ │
│ Question: "This new bug came in. Should we fix it now?" │
│ │
│ If bug blocks sprint goal → Yes, fix it │
│ If bug unrelated to goal → Add to backlog │
│ │
│ Question: "Can we add this small feature?" │
│ │
│ If supports sprint goal → Maybe, if capacity │
│ If distracts from goal → No, next sprint │
│ │
│ THE GOAL PROVIDES FOCUS │
│ When in doubt, ask: "Does this help achieve the goal?" │
└─────────────────────────────────────────────────────────────┘
Goal at Risk
WHEN SPRINT GOAL IS THREATENED:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EARLY WARNING SIGNS: │
│ • Blockers accumulating │
│ • Velocity behind target │
│ • Key stories not progressing │
│ • Dependencies delayed │
│ │
│ ACTIONS: │
│ │
│ 1. SURFACE IMMEDIATELY │
│ Don't wait until sprint end │
│ "The goal is at risk because..." │
│ │
│ 2. FOCUS RESOURCES │
│ Swarm on goal-critical items │
│ Defer non-essential work │
│ │
│ 3. NEGOTIATE SCOPE │
│ "Can we achieve a smaller version of the goal?" │
│ "What's the minimum that delivers value?" │
│ │
│ 4. REMOVE BLOCKERS │
│ Escalate aggressively │
│ SM drops everything else │
│ │
│ 5. COMMUNICATE │
│ Stakeholders informed │
│ No surprises at sprint end │
│ │
│ WORST CASE: │
│ Goal can't be met → Discuss why in retro │
│ Learn and improve goal-setting │
│ Not a failure, an input for improvement │
└─────────────────────────────────────────────────────────────┘
Measuring Success
Sprint Goal Achievement
EVALUATING SPRINT GOAL SUCCESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AT SPRINT REVIEW: │
│ │
│ Question: "Did we achieve the sprint goal?" │
│ │
│ ✅ FULLY MET: │
│ "Users can complete checkout with Apple Pay on web" │
│ All required functionality working in production │
│ │
│ ⚠️ PARTIALLY MET: │
│ "Users can complete checkout with Apple Pay" │
│ Works, but only for USD transactions (scope reduced) │
│ │
│ ❌ NOT MET: │
│ Apple Pay integration incomplete │
│ Cannot ship the functionality │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TRACKING OVER TIME: │
│ │
│ Sprint | Goal | Result │
│ ───────┼───────────────┼────────────── │
│ 21 | Payment MVP | ✅ Met │
│ 22 | Mobile launch | ⚠️ Partial │
│ 23 | Security | ✅ Met │
│ 24 | Apple Pay | ❌ Not met │
│ │
│ SUCCESS RATE: │
│ 50% fully met, 25% partial, 25% not met │
│ → Investigate: Are goals too ambitious? │
│ Are there recurring blockers? │
└─────────────────────────────────────────────────────────────┘
Retrospective Review
SPRINT GOAL IN RETRO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IF GOAL MET: │
│ │
│ CELEBRATE: │
│ "We achieved what we set out to do" │
│ │
│ ANALYZE: │
│ • What helped us succeed? │
│ • Was the goal appropriately sized? │
│ • Could we have been more ambitious? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IF GOAL NOT MET: │
│ │
│ UNDERSTAND (NOT BLAME): │
│ • What prevented us from achieving the goal? │
│ • When did we know it was at risk? │
│ • What could we do differently? │
│ │
│ COMMON CAUSES: │
│ • Goal too ambitious for capacity │
│ • Unexpected blockers │
│ • Scope grew mid-sprint │
│ • Dependencies not delivered │
│ • Estimation errors │
│ │
│ IMPROVE: │
│ • Better capacity planning? │
│ • Earlier blocker escalation? │
│ • Stronger scope protection? │
│ • Buffer for unknowns? │
│ │
│ THE GOAL: Learn and improve, not assign blame │
└─────────────────────────────────────────────────────────────┘