Planning through order
In Grunna, planning is not a separate activity. It is a consequence of ordering work.
Instead of estimating time, setting deadlines, or running planning sessions, Grunna uses a single ordered list of todos to make decisions visible.
The todo list is the plan
All executable work lives in one list.
The position of an item in the list defines its priority. The list is ordered from top to bottom, representing what will be worked on first, second, and so on.
There is no separate roadmap, sprint plan, or backlog view. The list itself is the plan.
Order creates consequence
Reordering the list is allowed at any time.
However, every change has an immediate and visible consequence. When a new todo is moved up, everything below it is pushed down.
This makes trade-offs explicit without discussion. Decisions are expressed through order, not debate.
Planning without estimation
Grunna does not estimate time for individual todos.
Instead, the list is informed by historical throughput. By observing how quickly work is usually completed, the relative position of a todo indicates when it is likely to be finished.
No dates are promised. The list shows consequence, not commitment.
Decision making without meetings
Because the impact of reordering is immediately visible, decisions can be made without additional planning sessions.
The Decision Owner adjusts the order of the list. The resulting outcome is visible to everyone.
This removes the need to explain, justify, or re-plan work verbally. The list communicates the decision.
Stability during execution
While work is being executed, the order of the list is treated as stable.
Executors focus on finishing active work and do not renegotiate priority mid-execution. This protects focus and reduces cognitive load.
The only exceptions are bugs:
- Stop-now bugs may interrupt active work and require dropping everything to fix immediately
- Next-to-pull bugs do not interrupt active work, but must be fixed before pulling the next planned todo
Bug-first is mandatory
In Grunna, bugs are not optional.
A product that does not behave as expected cannot be planned around. Allowing bugs to accumulate slowly erodes trust, clarity, and the meaning of progress.
Bug-first exists to protect correctness and understanding — not to optimize short-term throughput.
Two severities: stop-now vs next-to-pull
Bug-first does not mean that every issue requires immediate action. It means bugs are handled before new planned work continues.
Grunna uses two practical severities:
- Stop-now bugs — severe bugs that require dropping active work and fixing immediately
- Next-to-pull bugs — real bugs that do not justify interrupting active work, but must be pulled before starting the next planned todo
Stop-now bugs
A stop-now bug affects correctness, reliability, security, data integrity, or the team’s ability to understand what the product is actually doing.
When a stop-now bug is identified, active work is paused and the bug is fixed immediately.
Next-to-pull bugs
A next-to-pull bug is real, but not severe enough to justify interrupting active work.
It is fixed as soon as the current todo is finished — before pulling the next planned todo.
Bug ordering and classification
Bugs are still ordered work. When multiple bugs exist, the Decision Owner decides their order — just like any other todo.
The Decision Owner also owns the classification: what is a bug, what severity it has, and what is severe enough to interrupt active work.
A todo may be reclassified as a bug when it represents incorrect existing behavior. A bug may be reclassified as a todo when it is minor, cosmetic, or better handled through normal ordering.
What is a bug — and what is not
Because bugs can interrupt execution, Grunna requires a strict distinction between bugs and todos.
A bug is existing behavior that is incorrect, broken, or misleading compared to what the product is expected to do.
If something does not yet exist, it is not a bug.
Features, improvements, and new requirements are todos — even if they are important, urgent, or feel uncomfortable to delay.
Re-labeling feature work as bugs to bypass the queue undermines the entire system. Once this happens, priority loses meaning and trust erodes quickly.
Why this distinction matters
Bug-first works only if the definition of a bug is protected.
If everything is treated as a bug, nothing is. The queue becomes unstable, and execution turns reactive.
By enforcing a clear boundary, Grunna ensures that bug priority remains meaningful and that feature work remains visible as trade-offs rather than emergencies.
Why this works
Planning through order replaces abstract discussion with concrete consequence.
It allows teams to change direction without restarting the planning process, and it gives decision makers immediate feedback on what their choices mean in practice.
The result is less planning overhead and more finished work.