In the system I describe on this blog, the sprint is often the final piece of the puzzle. To understand its role properly, it helps to know the other building blocks: inboxes capture what comes in, the calendar holds time constraints, and the Kanban tracks tasks. The sprint then gives all of them a shared horizon.
You can, of course, adopt some parts of this system independently. But in my view, the whole is more useful than the sum of its parts. Without sprints, a Kanban can turn into an ever-growing list. Without inboxes, new requests are added haphazardly. Without a calendar, deadlines and appointments get mixed in with tasks you can choose to complete at different times.
The sprint holds these elements together by forcing a simple decision: what will I genuinely try to move forward over the next few weeks?
A contract with yourself
The term “sprint” comes from software development and agile methods. I do not adopt all of their rules here. I mainly keep one idea: instead of heading in every direction at once, you define a time frame and then choose reasonable goals for that period.
In a personal system, a sprint is therefore a contract you make with yourself. At the beginning, I deliberately select a number of tasks. More importantly, I decide that certain others will not be included. That second choice is essential: a sprint only has value if it also protects you from the temptation to start everything at once.
The contract does not necessarily mean finishing every selected task. Some depend on another person, involve many unknowns, or naturally span several sprints. Instead, I commit to moving each of them forward.
If a task was there at the beginning of the sprint and, several weeks later, absolutely nothing has changed, it probably should not have been selected. Perhaps it was too vague, not important enough, blocked from the outset, or simply incompatible with the sprint’s workload. That is not a problem: the gap provides useful information for making a better choice next time.
This distinction avoids two extremes. The first would be filling the sprint with small, easy subjects simply so you can check everything off. The second would be loading it with an unrealistic number of large projects, then treating the sprint as a failure because they were not all completed. The goal is to create concrete progress, not build a trophy board.
Choosing the length of a sprint
The right length depends heavily on the rhythm of your professional and personal life. A sprint that is too short leads to constant reviews and leaves little room for long tasks. A sprint that is too long weakens the contract: it becomes difficult to anticipate your availability, and the initial list gradually loses its meaning.
For me, a sprint often lasts around a month. That gives me enough time to move a range of subjects forward without pushing the next opportunity to reset the system too far away. It is not a universal rule, however. Someone whose work changes very quickly may prefer one or two weeks; someone who mainly organizes personal projects may choose a longer period.
The best reference point is the between-sprint review, which we will return to shortly. The period should be short enough for the review to correct the system regularly, but long enough for the sprint to produce something. It is also useful to choose a predictable rhythm—for example, a review at the end of every month—instead of deciding at the last minute that the sprint is over.
Handling new tasks during the sprint
The sprint’s time frame changes how you handle what arrives in your inboxes. When a captured item could become a new task, the first question is: can this wait until the next sprint?
If the answer is yes, I put it in the Kanban’s “Next sprint” column. It does not disappear, and I do not need to settle every detail immediately. I simply make an appointment with it for the next review.
This rule protects the initial contract. Without it, every interesting idea and every recent request can seem like a priority. The sprint then ends up holding far more tasks than it did at the start, while the original choices fade into the background.
If the subject genuinely cannot wait, I add it to the sprint. Unexpected events happen, and the system must remain flexible enough to absorb them. It is nevertheless useful to distinguish tasks that were present from the beginning from those added along the way. Ideally, these additions remain a minority. If they regularly dominate the sprint, you probably need to leave more room or reconsider how work is selected.
Take a simple example: I receive a tax notice. If the payment deadline falls within the current sprint, the task goes straight into the Kanban. If it falls later and no urgent preparation is required, I can put it in “Next sprint.” It will be reviewed at the right time without cluttering the work in progress.
This rule is not meant to be rigid. A very short task can sometimes be dealt with immediately, and a genuine emergency should obviously take precedence over the plan. What matters is that the exception remains deliberate. Adding a task to the sprint should be a decision, not a reflex.
The between-sprint review: the cornerstone of the system
Between two sprints, I set aside a proper block of time for the review. In an ideal world, you should be able to reserve at least half a day for it, somewhere quiet and free from distractions. Personally, I try to block out an entire day.
That may sound like a lot of time, but the review is not just about moving a few cards. It lets you check the real state of the system, step back, and decide what deserves a place in the weeks ahead. The more tasks the Kanban contains, and the more professional and personal areas overlap, the more valuable this time becomes.
The review has two main parts: closing the current sprint properly, then opening the next one.
Part one: closing the sprint properly
I start with the tasks in the “To archive” column. For each one, I check that the DoD—the Definition of Done—has actually been reached. A task should not be classified as complete simply because its main part is finished: the final actions included in its DoD count too.
“Closing” does not mean deleting. The task leaves the active Kanban, but I keep a record of its contents and the sprint during which it was completed. It can move to another board with one column for each completed sprint, an archive database, or a simple list. The format matters less than being able to recover what was accomplished, because we will return to it regularly—including immediately afterward, when opening the next sprint, as discussed below.
I also use this transition to complete various recurring tasks: administration, digital housekeeping, tidying up, or other maintenance work. Their nature depends entirely on each person’s life. This is one reason why sprint length and review date are personal choices: the ritual needs to fit into a realistic rhythm.
I then conduct a thorough review of every task that is still open. I check its status, DoD, next action, and the information stored in its description. A task marked “Waiting” may need a follow-up. Another may be less blocked than it appears. A third may no longer have any reason to exist.
This is therefore also the time to abandon some tasks. The sprint contract does not require you to preserve forever an idea that has become pointless. Consciously dropping an outdated commitment is healthier than carrying it from sprint to sprint without ever questioning it.
By the end of this first part, the Kanban should reflect reality. Completed tasks are archived, remaining tasks are clean, and abandoned subjects no longer create noise.
Part two: opening the next sprint
When opening the new sprint, the principle is not to dismiss anything too early. I gather the ideas, obligations, and wishes that might deserve a place. Then I decide which ones to do immediately, which ones to turn into well-structured tasks, and which ones to leave aside.
This decision-making is precisely why the review takes time. A task should not enter the sprint with a vague title and the hope that its meaning will become clear later. I can think about its DoD, its next action, its context, and any dependencies. I may also realize that it is too broad and split it up—or, conversely, that several small cards are working toward the same outcome.
I start with the “Next sprint” column. Every item there was postponed specifically to be reviewed at this moment. Each one must receive a decision: enter the sprint, wait again, be reworded, or be abandoned. The column must not become a junk drawer whose contents are automatically carried over.
I then look back through tasks archived during previous sprints. Some may reveal an action that needs repeating or a subject that returns regularly. How far back I go depends on the available time and sprint length. When I can, I like to go back as far as a year: this is particularly useful for rediscovering seasonal obligations that would not have occurred to me spontaneously.
Finally, I review the recurring task templates.
Using templates for recurring tasks
A recurring task does not necessarily need to remain active permanently. I prefer to keep a list of templates, then decide at each review whether it makes sense to create a new instance for the upcoming sprint.
These templates might cover, for example:
- Medical appointments and regular checkups;
- Vehicle or home maintenance;
- Business and personal accounting;
- Administrative or school deadlines;
- Preparing recurring meetings, such as a parent-teacher meeting or a nonprofit’s General Assembly.
The template serves as a reminder and a starting point. It may already contain a DoD, a list of usual steps, or useful documents. The new task remains adaptable, however: the maintenance required this month may not be the same as last time, and an administrative procedure may have changed.
The review is also an opportunity to develop this library. If a completed task is very likely to return, I can turn it into a new template. If a template is no longer relevant, I delete it. Like the rest of the system, this list should remain alive instead of growing indefinitely.
Tracking a few data points about your sprints
Statistical tracking is optional. I recommend getting sprints and reviews to work properly before building a dashboard. Precise data about a poorly maintained system mainly creates a misleading sense of control.
With a little experience, however, a few simple indicators can help. For each sprint, I record:
- The number of tasks present at the beginning of the sprint;
- The number of tasks remaining at the end of the sprint;
- The number of tasks added during the sprint.
For all three categories, I distinguish professional tasks from personal ones. This separation lets me identify an imbalance without having to maintain two entirely independent systems.
These numbers are not a grade. One task may represent five minutes of work and another several weeks, so counting cards measures neither effort nor value produced. Trends are informative, however. If many tasks are consistently added during the sprint, the initial contract may not match reality. If many tasks remain open without having moved forward, the sprint may be overloaded or poorly prepared.
I also like to add a short qualitative review: what went well, what went badly, what could have been done better, and the major tasks that had a real impact. A few sentences are enough. The aim is to preserve lessons that will help prepare the next sprint, not to write a detailed report on every day.
A framework for making better choices
The sprint is not an extra layer of planning designed to fill the calendar. It is a framework for making choices. It forces you to deliberately limit the number of subjects you try to move forward, then creates a regular moment to reconsider those choices.
Its value comes as much from what stays out as from what goes in. The “Next sprint” column gives an idea somewhere to land without breaking the current contract. The between-sprint review then ensures that the idea will actually be considered instead of forgotten in an endless list.
When this rhythm works, the system becomes more reliable. Inboxes continue to absorb new items, the Kanban honestly describes the state of tasks, and the calendar protects time constraints. The sprint ties everything together by giving it a temporary direction—firm enough to guide decisions and flexible enough to learn from reality.