Planning
Turning a goal into ordered engineering work: breakdowns, implementation plans, estimates, feature tracks.
Download all 64
- Break down an epic
Splits an epic into small, ordered vertical slices that each deliver testable value, with acceptance checks, dependencies and spikes. Use when an epic or large feature is too big to start.
- Estimate work as a range
Breaks engineering work into tasks and produces a range estimate with a confidence level, stated assumptions and the unknowns that need a spike. Use when asked "how long will this take?".
- Plan a spike
Turns a technical unknown into a time-boxed spike with a sharp question, exit criteria, cheapest-first experiments and a clear deliverable. Use when an unknown blocks a decision or an estimate.
- Write an implementation plan
Reads the codebase and writes an ordered implementation plan in small verifiable steps, with files to touch, tests, rollout and risks. Use before coding any change that spans several files.
- Assess a scope change request
Sizes a new request that lands mid-sprint or mid-project, shows what it displaces and its effect on dates, and lays out accept, swap, defer or decline with a reply to the requester.
- Assess technical debt
Catalogues the technical debt in a codebase or system, scores each item by its cost to the team against the effort to fix it, and turns the result into a paydown plan with quick wins first.
- Assign work across developers
Splits a set of tasks across named developers by skill, growth goals, availability and file overlap, to cut merge conflicts and avoid single points of knowledge.
- Build an engineering project risk register
Builds a risk register for an engineering project with causes, likelihood, impact, early warning signs, owners, responses and a review cadence.
- Choose Scrum or Kanban for a team
Recommends Scrum, Kanban or a hybrid for a team from its work mix, interruptions and release model, with the minimum set of rituals to start and how to review the choice.
- Coordinate a cross-platform feature release
Sequences one feature across backend, web, iOS and Android with API-first order, app review lead times, flags, minimum app versions and a joint launch date.
- Design an interrupt rotation
Designs a rotating interrupt or shield role that absorbs questions, small requests and support escalations for an engineering team, with intake rules, handoffs and load tracking.
- Design an issue tracker setup
Designs a Jira, Linear or GitHub Issues setup for engineering teams with projects, issue types, workflow states, fields, labels and conventions people will keep up.
- Design a kanban workflow
Designs a kanban board for an engineering team from how work really flows, with columns and their exit rules, WIP limits, classes of service, flow metrics and a review routine.
- Engineering manager
Acts as an engineering manager who balances delivery with team health, makes priorities and trade-offs explicit, grows people through direct feedback and shields the team from churn.
- Estimate from past projects
Estimates a new engineering project by reference class, comparing it with the team's finished projects and their real overruns, then adjusting for differences into a dated range.
- Estimate a software project budget
Estimates the full cost of building and running a software project, including people, cloud, licences, third-party services, contingency and year-one maintenance.
- Estimate team size for a project
Works out how many engineers, and with which skills, a project needs to hit a date, allowing for ramp-up, parallelism limits and coordination cost.
- Feature track
Takes a feature from open questions to a reviewed implementation in six gated steps, saving each step's artifact to the repo. Use for any change bigger than a quick fix.
- Find the critical path
Takes a task list with estimates and dependencies, finds the critical path and slack, spots work that can run in parallel, and shows which tasks actually decide the finish date.
- Map system ownership across teams
Builds a map of which team owns each service, job, repo, database and dashboard, finds orphaned or disputed systems, and proposes owners and a way to keep the map current.
- Measure DORA delivery metrics
Defines how to measure deployment frequency, lead time for changes, change failure rate and recovery time from your own tools, with data sources, caveats and gaming risks.
- Negotiate a delivery date
Answers "can you ship this by that date?" with what fits by then, what the full scope needs, the risks, and options to choose from, plus a reply that commits only to what the team can deliver.
- Pick starter tasks for a new engineer
Picks a graded sequence of first tasks for an engineer joining a team, from a first-day merge to a real feature, chosen from your backlog to cover the codebase and the people they need.
- Plan around a blocked dependency
Plans how to keep work moving when it waits on another team, a vendor or an approval, with an agreed contract to build against, stubs, parallel work, an escalation path and a fallback.
- Plan a bug bash
Plans a pre-release bug bash with charters, participants, environments and test data, a bug template, severity rules, live triage and how results feed the release decision.
- Plan a code freeze
Plans a code or change freeze around a peak period or major release with dates, what is allowed, an exception process, staffing, and how to thaw safely afterwards.
- Plan a codebase takeover
Plans the first weeks of owning a system you inherited, from access and knowledge capture while the old owners are reachable to a risk register, safe first changes and an ownership plan.
- Plan a change across services
Sequences a breaking change that spans several services, repos or clients into backward-compatible steps with deploy order, compatibility windows, owners and a check at each step.
- Plan the engineering response to a customer escalation
Plans the engineering response to a major customer escalation with facts first, triage, a workaround, a fix plan, an update cadence, one owner and a follow-up review.
- Plan a customer proof of concept
Plans a time-boxed proof of concept for a prospect with success criteria agreed up front, scope, environment, data, owners on both sides and a decision meeting.
- Plan a departing engineer's handover
Plans the weeks before an engineer leaves with knowledge sessions, docs to write, ownership and access transfers, and a dated checklist so nothing walks out of the door.
- Plan a distributed engineering team's workflow
Plans how an engineering team spread across time zones hands off work, with overlap hours, async rituals, review turnaround targets, decision records and on-call coverage.
- Plan the first iteration of a new project
Plans the first one to three weeks of a brand-new engineering project, from access and early decisions to a walking skeleton deployed to production, with exit criteria before feature work starts.
- Plan a hack week project
Scopes a hackathon or hack week idea down to one demoable result, with what to fake, a day-by-day plan for the team, cut points and what happens to the code after.
- Plan an outsourced work package
Plans handing a piece of engineering work to an agency or contractor team, with clear boundaries, interfaces, acceptance criteria, code standards, check-ins and a handback your team can own.
- Plan project milestones
Turns a multi-month engineering project into four to eight milestones, each ending in something demoable or shippable with exit criteria, risks retired and a date range.
- Plan a prototype to production
Audits a working prototype or hackathon build for what production needs (tests, security, data, observability, scale, ownership) and plans keep, harden or rebuild per part.
- Plan a service decommission
Plans shutting down an internal service or system with consumer discovery, traffic checks, a brownout, data archiving, dependency removal, DNS and cost cleanup.
- Plan a SOC 2 readiness project
Plans a SOC 2 readiness project for a small engineering organisation with scope, a control gap list, policies, evidence collection, owners, tooling choices and the audit timeline.
- Plan a sprint
Builds a sprint plan from a backlog and real capacity, with a sprint goal, committed and stretch items, dependencies, risks and what it deliberately leaves out. Use before sprint planning.
- Plan a stabilisation sprint
Plans a time-boxed stabilisation period after a run of bad releases or incidents, with entry rules, prioritised fixes by user impact, exit criteria and how to stop needing another.
- Plan a system go-live cutover
Plans the cutover from an old system to a new one with rehearsals, data freeze and migration, go or no-go criteria, a timed runbook, a point of no return, rollback and hypercare.
- Plan team capacity
Works out a team's real capacity for a period after time off, on-call and interruptions, splits it across features, bugs, debt and support, and flags over-commitment and single-person dependencies.
- Plan splitting an engineering team
Plans splitting a growing engineering team into two with ownership boundaries, who goes where, leads, shared rituals, on-call and a transition timeline.
- Prioritise a bug backlog
Ranks an open bug backlog by severity, frequency, users affected and fix cost, then picks what to fix this cycle, what to batch, what needs data and what to close.
- Prioritise developer experience fixes
Turns developer complaints, survey answers and build data into a ranked list of developer experience fixes (builds, tests, environments, reviews, tooling) by time saved and cost.
- Prune a team backlog
Cleans an overgrown engineering backlog into close, merge, keep and needs-owner groups with reasons, drafts closing notes, and sets rules that stop it growing back.
- Reduce a team's bus factor
Maps which systems and skills depend on one person, ranks them by risk, and plans cross-training, pairing, rotation and docs to spread the knowledge without stalling delivery.
- Replan a slipping project
Diagnoses why an engineering project is behind, compares recovery options (cut scope, move the date, change sequencing, add people) and drafts the replan and the message to stakeholders.
- Prepare PI planning
Prepares a SAFe-style program increment planning event for several teams with an agenda, team objectives, a dependency board, ROAM risks and a confidence vote.
- Run a production readiness review
Runs a production readiness review for a new or changed service against a checklist (observability, on-call, capacity, security, data, rollback, docs) and ends in a launch decision.
- Scope a software intern project
Scopes a software intern's project for a fixed term with a real outcome, weekly milestones, mentor check-ins, a fallback scope, stretch goals and a final demo.
- Scope a software maintenance agreement
Scopes post-launch support and maintenance for a client's software with what is covered, response targets by severity, an hours model, exclusions and monthly reporting.
- Scope a solo side project
Cuts a solo developer's app idea down to a version they can finish, with the one core loop, what to fake or buy, a week-by-week plan for limited hours and a cut list. Use before starting.
- Size backlog items relatively
Sizes a batch of backlog items against reference stories with relative points or t-shirt sizes, flags items too big or too unclear to size, and lists the questions that would settle them.
- Tech lead
Acts as a hands-on tech lead who keeps a team shipping by slicing work small, making and recording technical decisions, unblocking people and translating between product and engineering.
- Turn a design doc into tickets
Turns an approved technical design doc into tracker-ready tickets with titles, descriptions, acceptance checks, dependencies, labels and a suggested order.
- Write a bug severity policy
Writes bug severity and priority definitions with product-specific examples, fix-time targets, who sets them, and how bugs are escalated or downgraded, so triage is consistent.
- Write a change request for a CAB
Writes a production change request for a change advisory board with the change, risk rating, test evidence, implementation steps, rollback, impact and communications.
- Write a definition of done
Writes a team's definition of ready and definition of done as short checkable lists fitted to their stack and release process, with who checks each item and how to change it.
- Write an engineering project kickoff brief
Writes the kickoff brief for an engineering project with goals, scope and non-goals, team and roles, milestones, risks, ways of working and open questions.
- Write a RACI for an engineering project
Builds a RACI matrix for an engineering project across engineering, product, design, QA, security and ops, and flags decisions with no owner or too many approvers.
- Write a tech debt proposal
Turns a piece of technical debt into a business case with evidence, cost of delay, options, the smallest valuable paydown and success measures. Use when you need product or leadership buy-in.
- Write a technical roadmap
Writes an engineering roadmap from goals and known tech debt, with themes, sequencing, dependencies, capacity assumptions and what is deliberately left out. Use for quarterly or half-year planning.
Not: product requirements (product); architecture decisions (architecture); personal to-do lists (task-management).