Engineering Kickoff Template
A structured engineering kickoff template for PM-engineering alignment before sprint start. Covers goals, scope, dependencies, open questions, and success criteria — in under 45 minutes. Free to copy, download, and use. No signup required.
# Engineering Kickoff Template **Feature / Epic:** [Name] **Sprint / Milestone:** [Sprint Number] **Date:** [Date] **PM:** [Name] **Engineering Lead:** [Name] **Attendees:** [List] **Duration:** 45 minutes --- ## 1. Context (5 min) **Why are we building this?** > 2–3 sentences on the user problem, the business motivation, and why now. [Write here] **Success metric:** > One number that tells us if this shipped and worked. [e.g., "Onboarding completion rate increases from 42% to 60% within 30 days of ship"] --- ## 2. Scope (10 min) ### In Scope | # | Feature / Behavior | Notes | |---|---|---| | 1 | | | | 2 | | | | 3 | | | ### Out of Scope (Explicitly) | Item | Why Excluded | When It Might Come Back | |---|---|---| | | | | | | | | ### What "Done" Looks Like - [ ] Feature works end-to-end for all user types (Free, Pro, Admin) - [ ] Unit tests cover all business logic branches - [ ] API endpoints return correct responses for valid and invalid inputs - [ ] Error states are handled and show meaningful messages - [ ] Feature flag at 100% (if applicable) - [ ] Analytics event tracking added - [ ] [Add specific acceptance criteria] --- ## 3. Design (5 min) | Asset | Status | Link | |---|---|---| | Figma designs | ✅ / 🔲 | | | Mobile designs | ✅ / 🔲 / N/A | | | Edge case states (empty, error, loading) | ✅ / 🔲 | | | Responsive specs | ✅ / 🔲 / N/A | | **Open design questions:** | Question | Owner | Due | |---|---|---| | | | | --- ## 4. Technical Approach (10 min) > Engineering lead summarizes the implementation plan. PM listens for scope or logic surprises. **Backend:** [What new models, endpoints, or jobs are needed?] **Frontend:** [What new components or routes are needed?] **Infrastructure:** [Any new infra, queues, or migrations needed?] **Dependencies on other teams:** [API team / Data team / DevOps / etc.] --- ## 5. Risks and Open Questions (10 min) | Risk / Question | Owner | Due Date | Resolution | |---|---|---|---| | | | | | | | | | | **Blockers today:** | Blocker | Who's unblocking it | ETA | |---|---|---| | | | | --- ## 6. Timeline (5 min) | Milestone | Target Date | Owner | |---|---|---| | Spec / design finalized | | PM + Design | | Backend implementation | | Engineering | | Frontend implementation | | Engineering | | QA sign-off | | QA | | Feature flag at 5% | | Engineering | | Feature flag at 100% | | PM + Engineering | | Announcement / changelog entry | | PM | --- ## 7. Communication Plan | Stakeholder | Communication Method | Frequency | |---|---|---| | Leadership | Sprint review demo | Weekly | | Sales / CS | Async Slack update | On launch | | Users | In-app announcement | On launch | --- ## Action Items from This Meeting | Action | Owner | Due | |---|---|---| | | | | | | | | --- *Next sync: [Date and format — standup / async update / mid-sprint check-in]*
How to use this Engineering Kickoff template
Define success metric before writing scope
The success metric (Section 1) is the most important part of the kickoff. If PM and engineering can't agree on how to measure success, they'll also disagree on scope. Define it first. Everything else — in scope, out of scope, done criteria — flows from it.
Fill the Out of Scope table explicitly
Teams that only define what's in scope consistently face scope creep. Explicitly writing 'multi-language support: excluded from this sprint' prevents a stakeholder from assuming it's included. The more controversial the exclusion, the more important it is to write it down.
Have engineering explain the technical approach in their own words
When engineers describe the approach back to PM in the kickoff, they often surface scope surprises: 'Wait, to do X, we also need to build Y' or 'This requires a schema migration that needs a maintenance window.' These surprises are much cheaper to handle in the kickoff than in week 3.
Record action items with named owners before the meeting ends
End every kickoff by reading the action items list aloud, confirming owners, and setting due dates. 'Someone' as the owner means no one. The kickoff template's job is to eliminate ambiguity — action items without names are the biggest source of post-kickoff ambiguity.
Want a Engineering Kickoff grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How is an engineering kickoff different from sprint planning?
Sprint planning covers the whole sprint backlog across multiple features. An engineering kickoff is feature-specific — it's a focused session for one epic or feature set where PM and engineering align on scope, approach, and risks before the sprint starts. You might run 1–3 kickoffs per sprint for the largest features.
Should design be in the kickoff?
Yes — ideally design attends or has already synced with PM before the kickoff. If designs aren't ready, that's a blocker, not a 'we'll figure it out' — document it in the blockers table and don't start engineering work until it's resolved. Building without finalized designs doubles rework.
What if the feature is too large for 45 minutes?
Split the kickoff into two sessions: a scoping session (define in/out scope and success metric) and a technical deep-dive (approach, dependencies, risks). Features too large for a 90-minute total kickoff are probably too large for a single sprint — consider breaking the epic into smaller deliverables.
How do we handle kickoffs for bug fixes vs feature work?
Bug fixes rarely need a full kickoff — a Jira comment with root cause, fix approach, and test plan is usually enough. Use the kickoff template for features, epics, significant refactors, and migrations. The threshold: if the work involves cross-team coordination or takes > 3 days, do a kickoff.
Other free templates