Every engineering team eventually asks the same question: how do we get better at shipping without running ourselves into the ground?
The answer isn't longer hours or more standups. It's a tighter feedback loop between planning, execution, and review. That's what Cycles in Lumos are designed to enable.
What Is a Cycle?
A Cycle is a time-boxed container for work — typically one or two weeks. You pull issues from your backlog into a cycle, your team works through them, and at the end you get a clear view of what shipped, what slipped, and why.
It sounds simple. Most teams already do something like this. But the magic of Lumos Cycles isn't the concept — it's the execution.
The Problem with Traditional Sprints
Traditional sprint tooling has a few persistent problems:
Overhead: Planning a sprint in most tools requires copying issues, estimating points, balancing load manually, and updating three different views. It takes half a day.
Stale data: By Wednesday, the sprint board is already out of date. Issues get added, dropped, or deprioritized without any trace.
Meaningless retrospectives: End-of-sprint metrics are usually cherry-picked or not reviewed at all because the tooling makes it painful to extract them.
How Cycles Solve This
One-click planning
Lumos's AI-powered cycle planner suggests which issues to pull in based on priority, team capacity, and historical completion rates. You can accept the suggestion, tweak it, or start from scratch — but you're never starting with a blank page.
Real-time cycle progress
The cycle view updates live. As issues are completed, a progress bar fills. As new issues are added (scope creep happens), they're tracked separately so you always know your original scope vs. actual scope.
Automatic carryover
Issues that didn't make it get surfaced at the top of your backlog with a "slipped" label. No issue falls through the cracks. At the next planning session, you see exactly what you deferred and why.
Cycle insights
After each cycle, Lumos generates a summary: velocity trend, completion rate, scope change %, and which areas of the codebase had the most activity. No manual reporting required.
Tips for Getting the Most Out of Cycles
- Keep cycles short. Two weeks maximum. Shorter cycles mean faster feedback loops.
- Don't overfill. Aim for 70-80% of your theoretical capacity. Buffer for the unexpected.
- Protect the scope. Treat mid-cycle additions as exceptions, not the norm.
- Review the insights. The cycle review takes 20 minutes. Skip it and you lose the compounding benefits.
Teams that use Cycles consistently in Lumos ship more predictably, plan more accurately, and report higher team morale. It turns out that knowing what you're working on — and actually finishing it — feels really good.
