A fixed date with weekly iterations

Hybrid planning keeps the parts of a plan that the world fixes and runs the rest in short cycles. It fits projects like Klasna's physics launch, where an outside event sets the date and the details are still being learned.

Three things stay fixed. The date, because the exam season won't wait. The budget ceiling, because it is Hanna's limit. A few milestones, such as Vira's final program review, tutors vetted and checkout tested, which the opening depends on. Changing any of these is the sponsor's decision, not a planning choice.

One thing bends: scope below the must line. With the date and money capped, should and could items go in only if there is room, and they are the first to wait when work runs late.

Neither extreme works alone. A full task-by-task schedule from November is already half wrong by January; pure sprints with no dates lose the exam season. The hybrid takes the date from the first and the weekly rhythm from the second.

An iteration is a short, fixed stretch of work, here one week, with the same shape every time. From 4 to 29 January the physics team has four working weeks, so four iterations.

Monday: the team picks this week's items from the backlog, the ordered list of remaining work, musts first and only what fits the week. During the week: work moves across the board within its limits. Friday: the team shows the pieces that meet the definition of done, updates the risk register and the status from what it saw, and re-sorts the backlog for the next Monday.

The rhythm is what makes the hybrid work. Every Friday turns the plan into evidence: what is finished, what is stuck, which risks moved. Every Monday turns that evidence into the next week's choice. Problems surface within a week instead of at the end, and the backlog order always reflects what the team knows now, not what it guessed in November.

A definition of done is the team's written agreement about when a piece of work counts as finished: for a practice set, for example, written, solved by a second person and passed by Vira's review. A card is either done by that definition or it isn't.

"90% done" sounds like progress but tells the plan almost nothing. The last tenth of a task is often the slowest part: the review, the fix, the test with real people. Counting it as done makes the week look better than it is and hides work from next Monday's choice.

So on Friday an unfinished card goes back to the backlog with an honest estimate of its remaining days. That number, not a percentage, is what the plan needs: next Monday the team can see whether the card still fits and what it pushes out. At Klasna, Danylo puts it plainly: if something isn't done on Friday, it isn't "90% done", it is "two more days".

In a hybrid plan a milestone is not a date that quietly passes; it is a checkpoint placed on an iteration Friday. On that Friday the team checks one yes-or-no condition: is the milestone met?

If it is, the plan goes on. If it isn't, that Friday becomes a decision point, not a surprise in February. The lead has a short menu: re-plan the remaining weeks with the real numbers, cut scope below the must line to free time, or take the gap to the sponsor while there is still room to act. Moving the fixed date is the last resort and the sponsor's call, never the first reaction.

Suppose 22 January is the checkpoint for the last three tutors passing a demo lesson and only one has. The weekly rhythm has done its job: it has shown the gap with a week left. What fails is the team that lets the checkpoint pass with a shrug and carries the tutors over.

A work-in-progress limit caps how many cards a person or a board column may hold at once: for example, two in "doing" per person and three in Vira's "review".

The limit works because starting is not finishing. Six cards in progress means six half-done things, constant switching between them and nothing a learner can use. With a limit, a card has to leave a column before a new one enters, so work flows to "done" sooner.

When a column is full, the rule is: nobody starts new work; they help finish what's stuck. A full column is also a signal: it shows the bottleneck, the step where work piles up. Suppose on Wednesday Vira's review holds five practice sets against a limit of three and two tutors have finished their own cards. Starting new sets would only lengthen the queue; raising the limit would hide it; waiting for the weekend overloads one person. The two tutors help clear review instead, for example by solving the sample tasks of the waiting sets.

Short-cycle methods come with a full kit of rituals: a daily stand-up, planning sessions, reviews, retrospectives, estimation in points. A small project team needs only the ones that earn their place, and the test is one question: what decision does this ritual help us make? If the answer is none, drop it.

The physics team keeps three. The Monday pick decides what fits the week. The Friday demo shows what is really done. Fifteen minutes on risks checks which triggers have fired. Everything else is replaced or dropped. A daily 10:00 call fails because Vira teaches in the mornings; a two-line written update on the board by noon does the same job without a fixed hour. Points on every card would change no decision before 1 February, because the backlog order and the demo already do.

The default is remote and async: written updates people read when they can, meetings only where a live conversation changes the outcome.

A ritual earns its place when you can name the question it answers. Matching each one to its decision is also the quickest way to see which rituals are missing and which are dead weight.

For the physics team in January: the Monday pick from the backlog answers "what fits into this week?"; the Friday demo answers "what is really done?"; fifteen minutes on risks answers "which triggers have fired, and who acts?"; the two-line written update by noon answers "who is blocked and needs help today?"

Read the list the other way, too. If a question matters and no ritual answers it, add the smallest thing that does, often a written note rather than a meeting. If a ritual answers nothing, or a question another ritual already covers, drop it. The point is that every hour the team spends together turns into a decision; ritual for the sake of looking organized costs exactly the January days the launch doesn't have.

A demo shows work that meets the definition of done, in a form anyone can check. For the physics launch that means the diagnostic test taken by two real learners, a test purchase on the checkout's test site, a recorded demo lesson Vira has passed. A slide saying "checkout 80% done" is not a demo: it is a claim, and nobody can check it.

The demo turns progress into evidence the same way a trigger turns a worry into a date. It also cuts both ways, which is the point: if the checkout isn't on the test site by Friday, everyone sees it, and there is no hiding behind "almost". Unfinished work goes back to the backlog with its remaining days, not into the demo as a percentage.

How it fits together: the fixed date and milestones frame the plan, weekly iterations fill it, limits keep work flowing, and the Friday demo proves what is done. The next lesson asks what to do when reality stops matching the plan: re-plan from today.