Sprint Planning

Sprint Cadence

We operate on two-week sprints with the following rhythm:

Week 1:

• Monday: Sprint planning
• Wednesday: Mid-sprint check-in
• Friday: Engineering sync

Week 2:

• Monday: Engineering sync
• Wednesday: Demo prep
• Friday: Sprint demo & retrospective

Sprint Planning Meeting

When: First Monday of each sprint, 10am-12pm

Who: Full engineering team

Format:

1. Review Previous Sprint (15 min)

   • What shipped
   • What didn’t ship and why
   • Key learnings

2. Prioritize Backlog (30 min)

   • Product presents priorities
   • Team asks questions
   • Identify dependencies

3. Capacity Planning (15 min)

   • Team members share availability
   • Account for PTO, holidays, on-call
   • Set realistic commitments

4. Task Breakdown (45 min)

   • Break epics into tasks
   • Estimate story points
   • Assign initial owners
   • Identify blockers

5. Sprint Commitment (15 min)

   • Team commits to sprint goal
   • Document stretch goals
   • Set success criteria

Story Pointing

We use Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21

1 point: Trivial change, < 1 hour

2 points: Small feature, clear approach, 2-4 hours

3 points: Medium feature, mostly clear, half day

5 points: Larger feature, some unknowns, 1-2 days

8 points: Complex feature, significant work, 3-4 days

13 points: Very complex, needs breaking down

21+ points: Epic, must be broken into smaller stories

Sprint Goals

Each sprint has a clear, achievable goal that aligns with quarterly OKRs .

Good Sprint Goal: “Enable customers to configure automation scheduling through the dashboard”

Bad Sprint Goal: “Work on various dashboard improvements”

Characteristics of Good Sprint Goals

Specific: Clear what we’re building

Valuable: Delivers customer value

Achievable: Realistic for two weeks

Measurable: We know when we’re done

Daily Standups

Format: Async in Slack by 10am

Template:

Yesterday: [what you shipped]
Today: [what you're working on]
Blockers: [anything blocking you]

Sync Standup: Tuesday/Thursday 10am for 15 min (optional attendance)

Mid-Sprint Check-In

When: Wednesday of week 1

Purpose: Identify blockers early

Format:

• Review sprint progress
• Discuss blockers
• Adjust if needed

Sprint Demo

When: Last Friday of sprint, 2pm

Who: Engineering, Product, Customer Success, Sales (optional)

Format:

• Each feature owner demos what shipped (5 min each)
• Q&A and feedback
• Celebrate wins

Retrospective

When: After sprint demo (same day)

Who: Engineering team only

Format:

1. What Went Well (10 min)
2. What Could Be Improved (10 min)
3. Action Items (10 min)
   • Pick 1-3 concrete improvements
   • Assign owners
   • Review previous retro actions

Working with Product

Product owns what: What features to build and why

Engineering owns how: Technical approach and timeline

Collaboration: Product and Engineering work together on trade-offs

Technical Debt

We allocate 20% of each sprint to technical debt and refactoring.

How We Track It:

• Label issues with technical-debt
• Prioritize in sprint planning
• Balance with feature work

When We Take On More:

• After major feature launches
• When debt is blocking feature work
• Quarterly “clean-up” sprints