The start point of a task is the moment you commit to action and record the task's boundary conditions; the end point is the satisfaction of every stated acceptance criterion plus a verified handoff. Where you begin is a defined trigger and a written scope. What the finished task looks like is a checked deliverable that meets pre-agreed criteria. Everything between those two points is the work itself, and most scope failures happen because neither boundary was ever drawn explicitly.
Mechanism: how task boundaries actually form
A task boundary forms from three inputs: a trigger, a scope statement, and an acceptance test. The trigger starts the clock. It can be an event, a request, or a scheduled date. The scope statement lists what is inside and outside the work. The acceptance test defines what "done" means in observable terms. When any of the three is missing, the task has no true start or end, only activity.
Cognitively, this maps to the goal-setting literature. Researchers found that specific, difficult goals outperform vague "do your best" instructions, and that the effect depends on feedback and commitment rather than on the goal alone. A task with a written acceptance criterion is a specific goal. A task without one is a mood. Goal setting theory holds that effort rises when a person knows exactly what target they are aiming at and gets feedback along the way.
Operationally, think of a task as a function with an input, a transformation, and an output state. The start point is the input event after which work is assigned an owner. The end point is the output state after which the work no longer consumes attention, budget, or calendar time. A task that never reaches a state where it stops consuming resources has no real end, even if someone declares it finished.
The deeper reason boundaries matter is coordination cost. Work waiting for a boundary decision sits in a queue, and queues are where most project delay accumulates. Explicit boundaries shorten queue time because the next person knows when to act. That is the mechanism behind the professional caveat below.
Quantified context: credible numbers on boundaries and delay
Task boundaries are measurable even when published data is scarce. Cycle time, throughput, and work in progress (WIP) are the standard measurements, and they follow a stable relationship: average completion time rises as WIP rises for a fixed throughput. If a team completes 10 items per week while holding 30 open items, the implied average cycle time is about 3 weeks. Doubling open items without changing throughput roughly doubles cycle time. These are arithmetic identities, useful for planning, not study results requiring citation.
Work in progress limits exploit this. Limiting concurrent items caps queue growth and shortens the time from start to end. The practical threshold used in many service workflows is to set WIP limits a fraction below observed capacity, then raise them only when idle time becomes visible.
Time-to-first-action is the cheapest start-point metric: how long between trigger and first committed step. A useful tracking practice is to record it for every task in the same log as completion date, which gives you both boundaries on one line.
Edge cases where the default start and end fail
Some tasks have no clean trigger. Ambiguous initiatives, research questions, and "keep improving" programs start by definition and end only by governance decision. For these, the start point is the date a scope owner is named; the end point is a scheduled review that can formally close the work.
Some tasks have multiple owners and therefore multiple end points. A delivery task may satisfy engineering, security, and compliance acceptance criteria on different dates. The correct end point is the last criterion satisfied, not the first one announced. Handoff tasks are a separate edge case entirely.
Open-ended improvement work with no acceptance test; close it with a review gate instead. Tasks whose trigger is a person's memory rather than a recorded event; convert to a dated request. Deliverables with a formal receiver who can reject late; define rejection criteria up front. Regulated or high-stakes work where "done" requires signer authority. Recurring tasks where the start silently resets before the end is reached. Tasks split across vendors or teams, where each party believes the other owns the end.
Common misconceptions about where tasks begin and end
The most common misconception is that creating a ticket starts the work. Tickets record that a task exists. Work starts when an owner accepts it and the first action commits resources. Between those points, work waits, and the waiting is invisible in most task trackers.
A second misconception is that the end point is the moment output is produced. Output is not outcome. A document drafted is a draft; a document reviewed, accepted, and filed with all criteria checked is a completed task. A common professional caveat says output and outcome must be tracked separately, so teams do not mistake activity for completion.
A third misconception is that more detail always improves boundaries. Over-specified scope statements create brittle tasks that cannot absorb normal variation, and teams then reopen them endlessly. The counterintuitive detail: the best boundary definitions are strict about acceptance and loose about method. Teams that lock down steps produce more disputes than teams that lock down only the finishing condition.
Comparison: boundary models for different work types
| Work type | Start point | End point | Main failure mode | Best anchor |
|---|---|---|---|---|
| Simple production task | Assigned to an owner | Acceptance criteria met | Silent start, owner unnamed | Written criteria |
| Project phase | Gate approval | Phase gate review passed | Scope creep mid-phase | Gate calendar |
| Support request | Request logged | Requester confirms resolution | End declared without confirmation | Resolution test |
| Research question | Question scoped and funded | Review board accepts findings | No defined stopping rule | Review date |
| Recurring maintenance | Scheduled interval | Verified post-check | Interval resets before close | Checklist sign-off |
| Regulated deliverable | Authorized signature | Signer countersigns | Partial approval counted as done | Signature log |
The pattern across all six: the end point is a verified state, not an announcement. Each model pairs a start trigger with an acceptance test and a named verifier.
Timeline: the standard task lifecycle from trigger to verified end
| Stage | What happens | Typical boundary question | Exit condition |
|---|---|---|---|
| Trigger | Request, event, or schedule fires | Is this really work or noise? | Recorded and dated |
| Intake | Scope and acceptance drafted | What is out of scope? | Criteria written |
| Assignment | Owner accepts | Who is accountable? | Named owner |
| Execution | Work performed in bounded chunks | Is status visible? | First deliverable version |
| Verification | Criteria checked by verifier | Who signs off? | All criteria pass |
| Handoff | Receiver takes control | Has control transferred? | Receiver confirms |
| Closure | Task removed from active tracking | Can it reopen? | Log updated |
The gap between verification and handoff is where many "finished" tasks quietly reopen. A task is not closed until the receiver confirms control, and many organizations do not record that confirmation.
Practical actions: how to draw both boundaries before starting
Write the start trigger as a single dated sentence. If you cannot name the date or event, the task has not started. Record it in the same system where you track completion, so both boundaries live in one place.
Write the acceptance test as observable conditions. Use the format "when X is true and Y is checked by Z, the task is complete." Vague words such as "solid" or "complete" should appear nowhere in the test. If a word cannot be verified by a named person on a named date, replace it.
Set a WIP limit below demonstrated capacity and raise it only when idle time appears. Track cycle time from accepted start to verified end, not from ticket creation. That single change aligns reporting with reality.
Define the handoff recipient before execution begins. Give the recipient a confirmation step with a date. Treat confirmation as the final criterion.
Reconcile competing thresholds explicitly. If the project calendar says "phase ends Friday" and the acceptance test says "sign-off required," the acceptance test wins, and the calendar is a forecast. If a security review requires an approval that procurement has not scheduled, the task end is the later of those dates. State the rule: the end point is the last criterion satisfied, never the earliest date announced.
Ask three boundary questions at intake: who can declare this done, what evidence do they need, and what happens if the evidence is refused? Teams that answer all three at intake report fewer reopened tasks because the reopening rule was decided before emotion entered the process.
Limitations: what boundary math cannot tell you
Boundary definitions improve coordination, but they cannot make uncertain work certain. Novel research and creative work resist acceptance tests until something exists to test, and forcing premature criteria can suppress useful exploration. Conceptual limitations like this deserve naming rather than hidden.
The quantitative context above relies on arithmetic identities, not published studies, and should be used that way. Cycle-time targets are planning tools with wide real-world variance. No formula substitutes for direct observation of a team's actual queue.
Finally, this framework describes how to map boundaries, not how to diagnose why a given team's tasks never close. That diagnosis requires local data a general guide cannot supply. Use these sections to draw the map, then measure your own queue to correct it.