How I Plan Work: Two-Week Kanban
Scrum has real overhead. Daily standups, story pointing, sprint planning, and retrospectives add up to hours each week that could be spent building.
Sprint boundaries also add friction. If a priority shifts on a Wednesday, the team still waits for the next sprint to start. In practice, we adjust the backlog mid-cycle constantly. New work comes in and old work gets bumped. This is especially true on operational teams, where incoming requests don’t respect sprint boundaries. It undermines the point of locking the sprint down.
I kept the alignment and accountability and dropped the rest: a single Kanban board (To Do, In Progress, Done) governs the flow. Work enters when it’s ready and leaves when it’s finished.
I also limit work in progress per person as a forcing function: people finish what they start instead of scattering effort across half a dozen half-done items, and the cap pushes work to the finish line instead of letting it pile up mid-stream.
The only fixed meeting is a 30-minute review every two weeks.
We answer three questions:
- What shipped?
- What should ship next?
- Has anything in the outside world changed enough that we should pivot?
Then we reorder the board and get back to work.
The two-week cadence keeps the process light and gives the team enough room to think.
The board is visible to everyone, so few things come as a surprise. If a customer emergency lands on a Thursday we pull it straight into In Progress and eject something else. No round of approval meetings required.
That’s the whole system. A board, a WIP cap, and a 30-minute check-in every two weeks. It’s not much, but it’s held up across multiple teams.