Words matter. Not because naming things is a philosophical exercise, but because the words embedded in a tool shape the way people think about their work.
Every time a developer clicks “Create Issue,” they are, without realizing it, accepting a premise: that their work is fundamentally reactive. That it begins with a problem where its natural state is open until it has been closed.
Modelithe rejects that premise from the ground up; Modelithe claims that change management is the default – something is to be improved, not “fixed”.
The issues with “Issue”
The word issue comes from legal and medical traditions. An issue is a dispute, a complication, something that has gone wrong or is in contention. When the software industry borrowed the term for tracking work, it carried all that baggage along.
Over time, “issue” became the catch-all: bug reports, feature requests, support tickets, technical debt notes, all filed under the same label. The word stopped meaning anything in particular, which is precisely why it became universal. It is the project management equivalent of a junk drawer.
Calling your work items an “issue” implies that your baseline is broken.
That your product, as it stands, is somehow defective. That you are perpetually in a state of remediation.
This is the wrong mental model entirely.
Modelithe treats change management as the default.
The baseline is not broken; it is simply the current state of something that can always be improved. A bug is not a special category of work deserving its own nomenclature. It is a Task, like any other, arising from the observation that a specific Goal has not yet been achieved. There is nothing magic about bugs apart from we don’t want them, and we have not planned them.
Therefor, Modelithe‘s decision to rename “Create Issue” or “Create Task” or whatnot to “Increase Scope” is not cosmetic. It shifts the posture from something went wrong to we are deliberately expanding what we do. That shift changes conversations, changes planning, and changes how teams feel about their backlog. All of a sudden, we raise the bar just a little bit and highlight to the creator the consequences of adding a Task.
There is of course a risk that developers and others try to silently shove as much functionality under a previously agreed Task to avoid the visibility of having increased the Scope. But there are remedies to that. More on that later.
The Problem with “Ticket”
Some tools and teams replaced “issue” with ticket, and it is easy to understand why. A ticket at least doesn’t imply that something is wrong. It is neutral. It has a number, it moves through a queue, someone resolves it and it closes.
But a ticket is not a neutral word. It is a word borrowed from customer support, from helpdesks, from the paradigm of someone submitting a request to a system that processes it. A ticket describes a transaction, not an achievement. It frames the engineer as the queue, and the work as throughput.
That framing has real consequences. When work is a ticket, the goal becomes closing it. When work is a Scope with a Goal, the objective becomes achieving something. These sound like the same thing, but they are not. A ticket can be closed by deferring, deflecting, or marking it won’t-fix. A Goal demands an honest answer: was this achieved, or wasn’t it?
The ticket metaphor also subtly degrades the relationship between the person doing the work and the outcome. Tickets are processed, but Goals are pursued, and can be Achieved.
The Problem with “User Story” and “Story”
User Stories were introduced by Extreme Programming and popularized by Scrum as a way of expressing requirements from the perspective of the person who benefits: “As a [user], I want [something] so that [benefit].” The intent was good; it pushed teams to think about outcomes rather than specifications.
In practice, User Stories have a different fate in most teams.
The format becomes a ritual disconnected from its purpose. Stories are written by product managers to satisfy a process, reviewed in refinement meetings by engineers who already know what needs to be built, and then quietly stripped down to a title in whatever tool the team actually uses day-to-day. The “so that” clause (the part that explains why) is typically the first thing dropped.
What remains is the “As a user, I want…” preamble applied to work that has nothing to do with users at all: infrastructure tasks, refactoring, dependency upgrades, technical investigations. Teams contort the format to fit, or they maintain two parallel systems (stories for the product, tasks for engineering), which creates coordination overhead and a split source of truth.
A Story is also, structurally, a feature. It describes a desired capability. This makes it poorly suited to represent the full range of work that engineering teams actually do: bugs, investigations, improvements that users will never notice but engineers know matter. Forcing all of that into the User Story format produces cargo-cult process, not clarity.
Modelithe does not use User Stories because the Goal field achieves the purpose that the User Story format was designed for, without the ceremony.
A Goal answers the same question: what is the intended outcome, and for whom? It just does so in a single plain sentence, without a template, and without excluding the engineering work that does not fit neatly into a user-centric frame.
Modelithe provides the ability to create Use Cases and Requirements, which are related to requirements in general on the system level. If the User Story format is to be used by the teams, that belong to the Description of either a Requirement or Use Case. From a requirement point-of view, a Use Case can be reused between projects. Tasks cannot.
A Note on Gherkin
Closely related to the User Story tradition is Gherkin syntax, the structured language behind Behavior-Driven Development (BDD) tools like Cucumber. Where the User Story supplies the why, Gherkin supplies the what, expressed as concrete, testable scenarios:
Given [some initial context] When [an action is taken] Then [an observable outcome occurs]
Gherkin forces the author to think in terms of observable behavior rather than implementation details, and it creates a direct bridge between the description of a requirement and the automated test that verifies it. For user-facing Tasks where the acceptance criteria are genuinely behavioral, Given/When/Then can bring a discipline to the description field that free-form prose often lacks.
Whether it belongs in Modelithe is an open question. The honest answer is: sometimes, probably. One thing is for certain: the Goal field in Modelithe is not Gherkin and should not be.
A Goal is a single plain sentence describing the intended outcome; it is not a test script.
The free-form description field that sits below the Goal is exactly where Gherkin has potential. A Task whose Goal is “Users authenticates with their email without an receiving an error on first attempt” could carry a Gherkin scenario in its description that makes the acceptance criteria unambiguous and directly testable.
The risk is the same one that undermined User Stories: the format becomes mandatory ritual, applied uniformly to work it does not fit. Infrastructure Tasks, refactoring, technical investigations, and exploratory work rarely produce a clean Given/When/Then scenario. Forcing the format onto them produces either meaningless boilerplate or a quiet consensus to skip the description entirely.
Modelithe does not prescribe what goes into the description field. If your team works in a domain where BDD has genuine traction and your Tasks are predominantly behavioral, Gherkin in the description is a reasonable practice worth trying. If your work spans a wider range, it is a tool to reach for selectively, not a template to apply by default.
The Problem with “Title”
If “issue,” “ticket,” and “story” are wrong containers, “title” is the wrong content.
Every project management tool asks you to give your work item a title. And almost immediately, titles degrade. They become shorthand: “Fix login bug”, “Dashboard redesign”, “Performance thing from last week’s retro”. The title becomes a label for a conversation that happened once, in someone else’s head, that nobody else can fully reconstruct three weeks later.
A title describes what something is called. It does not describe why it exists, what success looks like, or who benefits when the work is done.
This is why Modelithe replaces “title” with Goal.
A Goal is a one-liner that answers the only question that actually matters: what does done look like, and why does it matter?
The difference in practice is significant. Compare these two backlog entries:
Title: Fix login bug
Goal: Users authenticates with their email without an receiving an error on first attempt
The first tells you something needs attention. The second tells you exactly what a successful outcome looks like, who it affects, and when the work can be considered complete. It is measurable. It is outcome-oriented. It removes ambiguity at the moment of creation, not during the retrospective.
The field name does quiet UX work. “What is this item called?” produces labels. “What is the Goal of this item?” produces clarity. Below the Goal sits a free-form description: context, acceptance criteria, links, decisions. But the Goal is the anchor that everything else hangs from.
What Is a “Scope”?
Once you stop calling things “issues,” “tickets,” or “stories” and stop giving them “titles,” you need a coherent name for the thing itself. In Modelithe, that name is Scope.
A Scope is not a new concept invented to be different. It is the precise word for what a Task, Epic, WorkPackage, or Feature actually represents.
Those items represent a bounded area of work with a defined intent. A Scope has edges. It begins somewhere and ends somewhere. It consumes real capacity and produces a measurable outcome. “Work”, on the other hand, is unbounded in time, and it means the act of doing something – not the completion of something.
Tasks, Epics, WorkPackages, and Features are all Scopes, each at a different level of abstraction, each carrying a Goal that explains why it exists, and each governed by the same vocabulary of actions:
- Increase Scope: add new work to the system (not “create issue”, “raise ticket”, or “add story”)
- Refine Scope: clarify or update an existing Goal and its description (not “edit”)
- Split Scope: divide one Scope into two when it has grown too large (not “duplicate” or “create subtask”); see below
- Decrease Scope: deliberately narrow or remove work (not “won’t do” or “close”)
- Approve Scope Change: formally accept a change to what has been committed
Every action in this vocabulary operates on the same concept: the bounded definition of work. The language is consistent whether you are talking about a single Task assigned to one developer or a Feature spanning multiple teams over several iterations. That consistency is not accidental. It is the point.
Visualise feature creep
When expanding the scope of a project requires clicking something called “Increase Scope,” the decision becomes visible. It is no longer hidden inside an innocuous “Add Task” or “New Ticket” button. No more surprising feature creeps.
Split Scope deserves particular attention, because Modelithe’s implementation of it exposes something that “Duplicate” and “Create Subtask” (the conventional alternatives) actively hide.
When a developer in a conventional tool duplicates a work item, or creates a child task under an existing one, the original remains untouched. The new item appears as an addition. Nothing about the interaction forces you to ask: what was in the original, and how does it now divide between the two? The answer to that question is left as an exercise for the reader, often never completed.
Modelithe’s Split Scope works differently.
When the action is triggered, two copies of the original Scope are presented side by side, both editable simultaneously, both starting as identical reflections of the item being split. The original is immediately marked as deprecated, replaced by the two new Scopes. The interface makes a silent demand: account for everything. You cannot split or duplicate a Scope and walk away with the original plus a vague child ticket. You must distribute the Goal (and the description, the context, the acceptance criteria) across the two new Scopes until both are coherent and complete on their own terms.
This matters because the act of splitting is almost always when you discover the original Scope was underspecified. When you try to divide a Goal into two distinct Goals, you find out whether the original Goal was actually clear, or whether it was just familiar. The side-by-side view creates productive discomfort. It does not let you pretend that splitting is a minor bookkeeping operation.
It is also a visual record of a decision. The deprecated original, with its two successors traceable from it, tells a story that a duplicated ticket or an orphaned subtask never could: we understood this work well enough to consciously divide it, and here is how we divided it.
The most consequential of these actions is Refine Scope, and Modelithe enforces a rule that makes its meaning explicit: once a Scope has reached In Progress or beyond, Refine Scope is no longer a silent edit. It triggers a warning, and in higher tiers, requires formal acknowledgment before proceeding.
This is not a bureaucratic safeguard. It is a statement about what a Goal actually is.
In most tools, editing a work item mid-flight is trivial. You open it, change the description, save. Nobody is notified. The history may or may not capture what changed. The person who accepted the work based on the original Goal has no idea that the target has moved. This is how scope creep happens not through large, deliberate decisions, but through dozens of small, frictionless edits to items that are already in progress.
Modelithe treats the moment work begins as the moment a Goal becomes a commitment. Before that point, refinement is expected and encouraged; Goals should be sharpened during planning, not mid-execution. Once an engineer has started working toward a Goal, changing that Goal is not an edit. It is a new agreement. It deserves to be treated as one.
“Started working” is of course also implied if the Task is put into an ongoing iteration, or the iteration which it is intended to be implemented in, is started.
The language already encodes this. “Refine Scope” carries a weight that “Edit” never did. The warning that appears mid-flight makes that weight felt.
A Scope Always Has a Goal
The relationship between Scope and Goal is what ties the whole model together.
Every Scope (at every level) carries a Goal. That one-liner is reviewed in an iteration review, refined when requirements change, and split when the work turns out to be larger than expected. It also connects directly to Modelithe’s broader philosophy: that all work is change management against a baseline, and that every change should be traceable from the Vision Statement down to the individual Task.
This mirrors how good engineering already works, but without the need of keeping sheets of Excel, Word-documents or Confluence pages in sync. The traceability comes for free in Modelithe even for a small team – not as a bolt-on process next to the tools. When a software engineer commits code, the commit message should answer: why does this change exist? When a team reviews a pull request, the first question is: what is this trying to achieve? The Goal field enforces that discipline at the planning stage, not after the fact.
The Vision Statement is the only blank page in Modelithe. Every Scope below it is a Goal in pursuit of the one above it.
Why This Matters for Growing Organizations
For a single developer tracking personal work, the difference between “title” and “Goal” might seem minor. But organizations do not stay small, and the terminology embedded in their tools scales with them.
When a company grows from one team to five, the question is no longer “what are we building?” but “why is each team building what they are building, and how do the pieces fit together?” A backlog full of titled issues or open tickets cannot answer that question. A hierarchy of Scopes, each carrying a Goal that connects upward to a Feature, which connects to a Use Case, which connects to a Problem being solved; that can.
The vocabulary of issues, tickets, stories and titles each arrived in the industry with good intentions and genuine use cases. But they all share a common failure: they describe things to process rather than outcomes to achieve. Modelithe is built around the opposite idea. Work is not a queue to drain. It is a series of deliberate expansions of what a product can do for the people who depend on it.
Modelithe is built for the entire journey from single developer to multi-team enterprise. Not by adding complexity up front, but by ensuring that the vocabulary established at day one (Goal, Scope, Increase, Refine, Split) remains coherent and meaningful at day one thousand.
The words you choose for your tools are the words your team thinks in. Choose them carefully.
Modelithe is the modern agile low-overhead method for small team growth to enterprise scale. Learn more about the philosophy of Modelithe