Kanban vs Sprints

Kanban and sprints are two ways to use the same board. Kanban, in the practical sense, means the cards keep moving through statuses with no dated container. A sprint, in Dayzen, means you turned cycles on and the work you are doing now sits in a cycle with a start and an end. The board does not go away when you add a cycle. The cycle does not appear just because you use columns.

This page is the choice. What a cycle does when it closes is cycles versus sprints. What the board is for, compared with a schedule, is Kanban versus Gantt. Neither of those needs to be repeated here as a definition.

Continuous flow

Leave cycles off when the work does not have a shared end date. Support queues, editorial calendars that publish whenever a piece is ready, and small teams that simply move cards to Done are flow. The question each morning is "what is in progress," not "what did we commit to this cycle."

Flow fails when everything is In progress and nothing forces a moment to look at what did not finish. That failure is not fixed by the word sprint. It is fixed by due dates, owners, and sometimes a cycle if you truly want a shared window.

There is no column limit. A flow board will not stop you from pulling more cards. If that discipline matters, it is a team rule, not a product rule.

A dated cycle on the same board

Turn cycles on when the group wants one active window: this cycle's tasks, then the next window you already created. A project has one active cycle. Cycles are optional. Another project in the same workspace can stay on flow.

Use a cycle when:

• You already name periods, such as "the next two weeks," and the list of tasks for that period is real.
• Unfinished work should be looked at when the period ends, not silently aged on the board.
• You will create the next cycle yourself when you know its dates. The product does not invent the next period for you.

Do not turn cycles on to look more formal. A cycle with no dates you believe, or a cycle that contains every task the company owns, is a second name for the whole board.

What you do not get by choosing sprints

Choosing a cycle does not install Scrum. There are no required planning meetings, reviews, or retrospectives in the product. There are no story points, no velocity, and no burndown chart. If your definition of a sprint needs those, Dayzen's cycle is not that definition. You can still hold the meetings. The product will not run them or score them.

Closing a cycle moves unfinished tasks only in the way the cycles article describes: into a later cycle that already exists, or off the cycle with an in-app notice if none exists. This page does not add a second version of that rule. Read it there before you promise the team an automatic next sprint.

The board's statuses stay the statuses. A cycle is not a column. "Sprint 12" should not be a status name. It is the cycle.

A simple choice

You need	Choose
Cards moving whenever they are ready	Cycles off
One shared date window for this project	Cycles on, one active
A schedule of what blocks what	The Gantt, with or without a cycle
Points, velocity, or a burndown	Not this product

Many projects need the first row. Some need the second. Almost none need you to rename the board.

Two projects, two answers

A maintenance queue stays on the board with cycles off. Tasks enter, get an owner, and leave. A release project turns cycles on because the group already plans a two-week window and wants unfinished release tasks visible at the boundary. The same people can work in both projects. They do not need one company-wide rule.

If the release project never closes its cycle, you chose flow and labeled it a sprint. Close it when the window ends, or turn cycles off and use due dates.

How to talk about the change

Say "we are adding a date window to this project" or "we are not." Do not say "we are switching to Scrum" unless you mean meetings you will run yourselves. People hear Scrum and expect points and charts. You will then spend a month explaining why the board looks the same. It looks the same because the work is still cards in statuses. The cycle is the container around the cards you included.

Trying a cycle without betting the team

Pick one project that already talks in two-week windows. Turn cycles on there. Create the current cycle with the dates you are actually in, and the next one only if you know those dates. Put this window's tasks into the active cycle. Leave the backlog of "someday" tasks out of it. Those can sit on the board without a cycle, or in the later cycle if you created one and they truly belong there.

Do not convert every project the same day. The maintenance queue will look worse inside a fake sprint than it does as flow. Review the choice at the first close. If nobody uses the boundary, turn cycles off and keep due dates. If the close surfaces unfinished work people had forgotten, keep the cycle and read the rollover rules before you tell the team the cards will move themselves.

Avoid a status named after the sprint. Avoid a tag named after the sprint if the cycle already groups the tasks. Two containers for the same window will drift. The cycle is enough.

People may ask for points so they can "do scrum properly." Points are not on the task. An estimate in minutes is available if you need effort, and it is not velocity. Say that at the start so the trial is judged on the date window, not on a chart you will not have.

Conclusion

Kanban versus sprints is continuous flow versus an optional dated cycle on the same board. Leave cycles off when work has no shared window. Turn them on when one active cycle matches how the project is already planned. Do not expect Scrum events, story points, or a burndown. The board remains the status picture, in /pms.

One mistake to avoid

Do not put every open task into the active cycle so the cycle looks full. A cycle that contains the entire backlog has no window. Leave someday work out. The board can still show it. The cycle should name what this period is actually for.

Judge the trial by one question at the close: did the window make unfinished work visible, or did it only rename the board? If it only renamed the board, turn cycles off. Due dates can remain. You have not failed the project. You have learned that this one is flow.

Keep the maintenance project on flow even if the release project likes the cycle. Forcing one rule onto both will make the queue look late every two weeks when it was never a commitment window.