jira-sprint-planning

Jira Sprint Planning Skill

This skill provides patterns for effective sprint planning using Jira, including capacity planning, ticket prioritization, and sprint organization.

Sprint Planning Process

Pre-Planning (Before Meeting)

1. Backlog Grooming

   • Ensure tickets are refined and estimated
   • Clear acceptance criteria on all candidates
   • Dependencies identified
   • Tech debt and bug tickets included

2. Capacity Calculation

   Team Velocity: [average points completed per sprint]
   Available Days: [total team days - PTO - meetings]
   Capacity: ~80% of velocity (buffer for unknowns)
   

3. Priority Review

   • Product priorities aligned
   • Critical bugs identified
   • Tech debt allocation (typically 10-20%)

During Planning

1. Review Sprint Goal

   • Define 1-2 key objectives
   • Align with roadmap/OKRs
   • Communicate to stakeholders

2. Select Tickets

   • Start with highest priority
   • Check dependencies
   • Balance feature/bug/tech-debt
   • Don't exceed capacity

3. Validate Commitments

   • Team agrees on selection
   • Dependencies confirmed
   • Risks identified
   • Sprint goal achievable

---

Jira Sprint Operations

Creating a Sprint

// POST /rest/agile/1.0/sprint
{
  "name": "Sprint 42",
  "startDate": "2024-01-15T09:00:00.000Z",
  "endDate": "2024-01-29T17:00:00.000Z",
  "originBoardId": 123,
  "goal": "Complete user notification system"
}

Moving Tickets to Sprint

// POST /rest/agile/1.0/sprint/{sprintId}/issue
{
  "issues": ["PROJ-123", "PROJ-124", "PROJ-125"]
}

Sprint Queries (JQL)

# Current sprint tickets
sprint in openSprints() AND project = PROJ

# Sprint backlog
sprint = "Sprint 42" AND project = PROJ ORDER BY rank

# Unassigned in sprint
sprint in openSprints() AND assignee IS EMPTY

# Blocked tickets
sprint in openSprints() AND labels = blocked

# Carry-over candidates
sprint in closedSprints() AND status != Done AND
  updatedDate > startOfWeek(-1)

---

Capacity Planning

Team Capacity Template

Team Member	Days Available	Focus Areas	Notes
Developer 1	10	Backend, API
Developer 2	8	Frontend	PTO: 2 days
Developer 3	10	Full-stack
Total	28 days

Point Capacity Calculation

Historical Velocity: 40 points/sprint (average of last 3)
Team Availability: 90% this sprint
Adjusted Capacity: 36 points

Allocation:
- Features: 25 points (70%)
- Bugs: 7 points (20%)
- Tech Debt: 4 points (10%)

Sprint Loading Guidelines

Load Level	Description	Risk
< 70%	Under-committed	Low, may add mid-sprint
70-85%	Optimal	Low
85-95%	Full	Medium
> 95%	Over-committed	High, likely carry-over

---

Ticket Selection Criteria

Must Include

• P1 bugs (production issues)
• Committed dependencies for other teams
• Regulatory/compliance deadlines
• Items blocking other work

Should Include

• Highest priority features
• Tech debt with clear ROI
• P2 bugs affecting users
• Sprint goal supporting items

Consider Including

• Quick wins (low effort, high value)
• Research spikes for future work
• Documentation updates
• Developer experience improvements

Avoid Including

• Poorly defined tickets
• Items with unresolved dependencies
• "Stretch goals" beyond capacity
• Tickets requiring unavailable team members

---

Sprint Goal Framework

Good Sprint Goals

• Specific and measurable
• Achievable within sprint
• Aligned with product objectives
• Valuable to users/business

Examples:

• "Launch beta of notification system to 10% of users"
• "Reduce checkout error rate from 5% to 1%"
• "Complete API migration for mobile team"

Bad Sprint Goals

• "Work on notifications" (too vague)
• "Fix bugs" (not specific)
• "Finish everything" (not realistic)

---

Sprint Board Setup

Columns (Example)

To Do | In Progress | Code Review | QA | Done

Swimlanes

• By assignee
• By epic
• By priority (expedite lane for urgent)

WIP Limits

Column	Limit	Reason
In Progress	2 per person	Focus
Code Review	5	Keep reviews flowing
QA	3	Prevent bottleneck

---

Sprint Ceremonies

Sprint Planning (2-4 hours)

• Review sprint goal
• Select and commit to tickets
• Identify dependencies and risks
• Assign initial owners

Daily Standup (15 min)

• Progress since yesterday
• Plan for today
• Blockers

Sprint Review (1-2 hours)

• Demo completed work
• Stakeholder feedback
• Acceptance of stories

Sprint Retrospective (1-1.5 hours)

• What went well
• What to improve
• Action items for next sprint

---

Mid-Sprint Adjustments

Adding Work

Criteria for adding:

• Critical bug in production
• Blocking another team
• Takes less time than available slack
• Team agrees to adjustment

Process:

1. Discuss in standup
2. Evaluate capacity impact
3. Consider removing equal-sized item
4. Document reason for addition

Removing Work

Criteria for removal:

• Blocked and won't unblock this sprint
• Scope grew significantly
• Higher priority item needs space
• Team member unexpectedly unavailable

Process:

1. Communicate early
2. Move to backlog (not delete)
3. Document reason
4. Adjust sprint goal if needed

---

Sprint Metrics

Key Metrics to Track

• Velocity: Points completed per sprint
• Planned vs Completed: Commitment accuracy
• Carry-over: Items not finished
• Scope Change: Items added/removed mid-sprint
• Bug Ratio: Bugs vs features completed

Health Indicators

Metric	Healthy	Warning	Action Needed
Completion	> 85%	70-85%	< 70%
Carry-over	< 10%	10-20%	> 20%
Scope Change	< 15%	15-25%	> 25%
Blocked Time	< 10%	10-20%	> 20%