Cycles vs Sprints

A sprint, in Scrum, is a fixed period of committed work with a backlog, a planning meeting, a review, and often points and a velocity chart. A cycle, in Dayzen’s project tools, is a named date range on a project. You can put tasks in it. Only one cycle on that project is active at a time. When it closes, unfinished tasks move forward only if another cycle is already sitting on the calendar after it.

Those are not the same object. Calling a cycle a sprint because both have an end date will make people expect charts and ceremonies the product does not run.

What people mean by a sprint

On a team that actually practices Scrum, a sprint usually includes:

• A goal for the period.
• A set of work pulled from a backlog.
• Estimates, often in story points.
• A burndown or a velocity number after a few sprints.
• A rule for what happens to unfinished stories, decided by the team in a meeting.

The software may support that. Many issue trackers do. The word “sprint” in a menu does not mean the practice is installed. If the screen has no points and no burndown, you do not have that practice. You have a date range.

What a cycle is

A cycle is optional. A project can run forever on a board with no cycle at all. When you turn cycles on, each one has a name, a start date, and an end date. Tasks can be placed in a cycle. The project is not allowed to have two active cycles at once. You close the current one before another can be the active cycle.

That is the whole mechanism. There is no story-point field on the task, no velocity score, and no burndown or burnup chart. Do not report those numbers from this product. If a stakeholder asks for velocity, the honest answer is that you are not collecting the data that velocity needs.

Use a cycle when a date box helps the team: “this is the work we intend to finish between the 1st and the 14th.” Skip it when the board is a continuous queue and a fake end date would only create leftovers.

What happens when a cycle ends

Unfinished means the task’s status is not in the Done or Closed group. Those tasks are the ones that move. Done and closed tasks stay behind with the cycle you closed.

The next cycle is not created for you. Rollover looks for another cycle on the same project whose start date is after this cycle’s end date, and it picks the earliest of those.

• If that later cycle exists, the unfinished tasks are moved onto it.
• If it does not, the unfinished tasks are taken off the cycle. They remain in the project, with no cycle. Workspace members can get an in-app notice that those tasks are now uncycled.

You can close a cycle early, or a scheduled job can close it once the end date has passed. Either way, the move follows the rule above. Plan the next cycle before you close this one if you want the leftovers to land somewhere. Otherwise you will have a pile of tasks with a blank cycle, which is easy to miss if your filter is “current cycle.”

This is not a sprint review. Nobody is required to hold a retro, re-estimate, or accept a new goal. Those are team habits. The software only moves or clears the cycle on incomplete tasks.

A short example

A project has Cycle 12, 1–14 March, and Cycle 13, 15–28 March, already created. On the 14th, six tasks are still in progress and four are done. Closing Cycle 12 leaves the four done tasks on Cycle 12 and moves the six onto Cycle 13, because Cycle 13 starts after Cycle 12 ends.

If Cycle 13 had not been created, those six would sit on the project with no cycle, and people in the workspace could see a notice that the tasks were uncycled. The work would not disappear. It would fall out of the cycle filter.

What to tell the team before the first close

Say the rules in one message, before anyone treats the cycle name as a promise to a client.

The cycle is a date window, not a commitment ceremony. Tasks in it are the ones you intend to finish inside the window. Tasks you already know will slip should not be parked there to make the list look full.

Done and Closed stay on the cycle you close. Anything still in an earlier status is unfinished for rollover purposes, even if someone feels it is “basically done.” If that status is wrong, change the status before you close. Do not close first and hope.

Create the next cycle first if leftovers should have a home. Name it and set its start after this cycle’s end. If you skip that step, unfinished tasks remain on the project and drop off the cycle. People who filter to the active cycle will think the work vanished. It did not. The filter hid it.

You do not owe a velocity number at the end. You owe an accurate list of what finished and what moved.

How to use a cycle without pretending it is Scrum

1. Leave cycles off if a board is enough.
2. If you want a date box, create the cycle with a real start and end, and create the following one before the first one ends.
3. Put tasks in the cycle when the team intends to finish them in that window. Do not dump the entire backlog in to make the count look serious.
4. At the end, close the cycle and check where unfinished tasks went.
5. Do not invent points or a velocity slide from task counts. A count of tasks moved forward is not velocity.

A Kanban board can still be the daily view. The cycle is a filter and a date boundary on top of the same tasks. You do not have to stop using statuses because a cycle exists.

How this works in Dayzen

Dayzen calls this feature a cycle, not a sprint. Cycles are off until a project enables them. Each cycle has a name and a start and end. The project can have only one active cycle. Closing it, manually or when the end is reached, runs the rollover described above: incomplete tasks, judged by status group, move to the next already scheduled cycle or become uncycled.

Dayzen does not store story points, does not draw a burndown or burnup, and does not compute velocity. An in-app notice can fire when tasks are left without a next cycle. That notice is not a claim that the product emails a sprint report. There is no sprint report.