Planning
Write issues people can act on, plan in cycles instead of deadlines, and keep work in flow.
Method
- Write issues, not ticketsA ticket is a request to be processed. An issue is a problem to be understood. The words you use change the work you do.
- Plan in cycles, not deadlinesDeadlines are predictions dressed as commitments. Cycles are a heartbeat. One creates anxiety; the other creates rhythm.
- Keep work in flow: WIP limitsStarting work is easy and feels productive. Finishing work is what ships. WIP limits force the difference.
- Roadmaps as living documentsA roadmap that never changes is a lie you agreed to tell. A roadmap that changes constantly without warning is noise. The craft is in between.
From the blog
- How to run OKRs that don't rot by week threeMost OKRs die quietly: written in a kickoff doc, copied into a slide, never updated again. The fix isn't a better template — it's putting the objective on the same schema as the work, so progress rolls up by itself and a stale number is impossible.
- OKRs vs KPIs: the goal is not the gaugeTeams confuse the goal they're chasing with the gauge that measures it, then wonder why their dashboard is full and their direction is empty. The difference, and why it matters.
- Forecast delivery dates without estimating a thingStory-point estimates are slow, contentious, and usually wrong. Probabilistic forecasting answers 'when will it ship?' with a confidence level — using only the completion data your team already produces.
- Cycle planning that survives realityMost sprint plans are fiction by Wednesday. How to plan cycles that bend instead of break — scoping for the interruptions you know are coming, not the ones you wish weren't.
- Cycle reviews: closing the loop on every sprintPlanning a cycle is the easy half. The review at the end — what shipped, what slipped, and why — is where teams actually get better. How to run a cycle review that changes the next plan instead of just narrating the last one.
- Sprint planning with AI: faster, and still yoursAI can draft the sprint in seconds, but the plan is still yours. How to use an agent to prep, scope, and forecast a sprint without losing the judgment calls.
- Capacity planning without the spreadsheet gymnasticsMost capacity planning is a spreadsheet that is wrong by Wednesday. Plan real capacity from live signals — availability, WIP, and throughput — not a guess.
- What is a kanban board? A practical guide for software teamsA kanban board is columns of workflow states and cards that move through them, with a hard limit on how many cards can be in progress at once. Here's what actually matters and what's just decoration.
- RICE vs MoSCoW vs ICE: choosing a prioritization frameworkThree popular ways to rank what to build next, what each is actually for, and the honest limits of all of them — a framework structures the argument, it doesn't make the call for you.
- Definition of Ready vs Definition of Done: a practical guideTwo checklists, two different jobs: one decides whether an issue is workable before a sprint starts, the other decides whether it's actually finished. Confusing them is a common source of sprint slip.
- Async standups: how to run daily check-ins without a meetingAn async standup answers the same questions a sync one does, written instead of spoken, on your own time. Here's when that trade is worth it, the format that works, and where it breaks down.
- Sprint velocity: how to actually measure it (and where it lies to you)Velocity is completed work per sprint, averaged over time — useful for one team's own capacity planning, and easy to misuse as a productivity score. The formula, a worked example, and the three ways it lies.
- Can AI estimate story points for you? Does it actually work?An LLM can read a ticket and guess a plausible point value, and it's genuinely useful at flagging outliers. It can't know your team's calibration or the complexity a ticket doesn't mention. The honest verdict.
- How to run a blameless retrospective that actually changes what happens nextMost retrospectives produce a list of feelings and no follow-through. A blameless retro works when it separates what happened from who's at fault, and when every real finding leaves the room as a tracked issue instead of a line in a doc nobody reopens.
- Backlog refinement without the weekly slogRefinement turns into an hour nobody enjoys when the meeting tries to review the whole backlog instead of just the next slice of work. A three-tier backlog and a checkable definition of 'ready' keep the meeting short and the sprint actually plannable.
- Writing PRDs engineers actually readA PRD that engineers skim instead of read usually fails the same test: it doesn't answer what problem, for whom, and how you'll know it worked in the first few lines. Everything past that is detail — and the most-skipped, most-necessary section is what's explicitly out of scope.