Decomposition and Shaping: Making Work Bounded

When a team receives a large request, the first temptation is to hand out tasks by file: one person takes the database, another the API (application programming interface), a third the interface. A list like that still does not explain what change the user will see, what remains unknown, or where the boundary of finished work lies.

In this unit, decomposition means dividing work so that it reduces uncertainty and gives the team results it can check. Shaping comes before it: working out a solution before it is accepted into the work queue. Shaping clarifies the problem, the general approach to solving it, the scope, the dangerous unknowns and what the team is deliberately not doing. It is not a complete script of every click, and it is not a mathematical proof of a deadline.

Artificial intelligence (AI) can help formulate and organise the work. But a generated plan is not the product owner's approval.

The examples below are for teaching. The clients, the studio team, the data, the timelines and the results are invented, except where a real public GitHub issue is explicitly mentioned. Any time limit in an example is a boundary for discussion, not a productivity forecast or an estimate for a particular team.

By the end of this unit you will be able to:

• tell a result for the user apart from a list of technical outputs;
• go from a raw idea to a sufficiently defined pitch (a short description of a potential bet) with boundaries and open questions;
• distinguish appetite (the amount of time a team is willing to invest) from an estimate (a forecast of the expected work);
• spot tasks that are oversized, too small, or secretly dependent on each other;
• show an agent the boundaries, dependencies, success criteria and unknowns before any tasks are created.

Start from the outcome, not the number of tickets

An output is what the team ships: a screen, an endpoint, a migration, a document or an agent tool. An outcome is the change that becomes possible for the user or the business. A screen can appear while the customer still phones in to change a booking; then there is an output, but not the outcome anyone wanted.

Example. A studio owner asks for a client portal, but it turns out people mostly phone to check the time of their booking. The first useful result can be more modest: the client opens a confirmation and sees the current time of their next appointment. Rescheduling, documents, payment and chat remain open options for now.

Do not invent a target such as "reduce calls by 40%" if the team cannot tell calls about times from other calls and does not know the baseline volume. First define how to count these particular enquiries relative to active bookings, what to compare the result with, and which events to exclude.

A description of an outcome is useful when it names the user, the situation and an observable consequence. "Improve the experience" and "add a portal" give no criterion by which a failed implementation could be rejected.

In his article The Four Big Risks, Marty Cagan names four risks: value to the customer, usability, technical feasibility and business viability. These are questions for discovery (finding out what the problem is and testing options), not four mandatory Jira tickets. For the portal, the team needs to find out whether the client really needs to view their booking; whether they can find and read it; whether the system can show the current record; and whether the access and support it requires carry unacceptable risk or cost. Other significant risks may surface, and the list on its own does not prove the idea is worth building.

When this breakdown is not needed. If a production service is already down and the team has a tested recovery playbook, they restore the service first instead of starting a long product-discovery session. If the change is fixing an obvious mistake in a label that affects neither security nor a contract, a short task with a precise expected result may be enough. The depth of shaping should match the risk, the cost and the irreversibility of the decision.

A complete simple walkthrough. The studio owner says: "We need a client portal." That is the name of a possible solution, not a stated need. In conversation it emerges that clients phone to check the time of their booking. The team clarifies which clients, when it happens, what they see today, and which mistake costs the most. The first useful result can be modest: the client opens the confirmation and sees the current time of their next booking. It is not yet decided whether rescheduling, documents, payment or chat are needed.

Success is not defined by inventing a figure such as "reduce calls by 40%". First the team checks whether it can tell a call about timing from other calls at all, and whether it knows the baseline volume. If no such records exist, that is a separate uncertainty. Once a first step is available, a measure can be chosen: for example, the number of enquiries specifically about the status of an upcoming booking per a given number of active bookings. Before launch the team defines where the numerator and denominator come from, what the comparison baseline will be, and which events are not counted.

Levels of work: a useful map, not a mandatory Jira hierarchy

Conversations about work often move between five levels:

Level	Question	Teaching example
Direction or business goal	Why is the team making this change?	Less manual servicing of bookings that already exist
User capability	What will the user be able to do?	See their booking and choose another free time
Bounded change	Which part of the capability has a clear edge?	Move one of their own upcoming bookings to an available slot
Technical task	What technical result has to be produced or verified?	Determine whether the calendar provider supports an atomic slot check
Implementation step	What is the next action within an agreed task?	Add an expected_version field to the booking-change request

Common terms can be roughly matched to this map, but they should not be treated as universal Jira levels. An epic often groups work around a direction or a large capability; a feature often names a user capability or part of one; a task is a bounded change or a technical result; an implementation step is a concrete next action inside a task. Different teams use these words for different scales, and an implementation step may be a checklist item rather than a separate issue. For example, "client self-service" could be an epic, viewing an upcoming booking a feature, changing one upcoming booking a task, and adding expected_version to the request an implementation step.

These are conceptual levels, not a rule like "every epic must have three features with five tasks each". Teams arrange their issue-type hierarchies differently, and sometimes technical work is a valuable result in its own right. Verifying backup restoration, migrating a vulnerable library or reducing compute costs can matter even when the customer gets no new screen.

The reverse also holds: a task "add a booking_status column" may be a necessary step, but the column alone does not prove that the client sees an accurate status. Before creating separate tickets, mark how each one connects to the goal, or say plainly that it is exploratory, operational or required supporting work.

What shaping actually produces

In Shape Up, the method developed by Ryan Singer at Basecamp, shaped work has three properties:

• Rough, on purpose. It shows the direction and the important decisions, but it does not fix the colours, the name of every variable or every interface variant before the people doing the work have seen the real conditions.
• Solved, at the right level. The main elements of the solution already fit together; significant visible contradictions and questions that could block the team have been worked through or explicitly set aside for verification.
• Bounded. It is defined what is in, where to stop and what will not be in this version.

"Rough" does not mean "a one-sentence idea; let the team work it out". "Solved" does not mean "every field and every error scenario fixed for ever". The boundary leaves the people doing the work room for professional judgement within the agreed result. A pitch like this should be clear to someone who was not in any of the earlier conversations.

For rescheduling a booking, for example, the following can already be known: the user must see only their own record; the new slot must stay free even when another client competes for it; the confirmation appears only after the new time has been recorded. The button colour and the exact wording of a hint can be left to the designer. But the behaviour when two clients pick the last slot at the same moment should not be left as an invisible detail if it determines whether the product is correct.

In Singer's book, the four steps of shaping lead from setting boundaries, to the elements of the solution, to working through rabbit holes (risks and unexamined details that could derail the plan), to a written pitch. Here we adapt that sequence to a small studio and to working with an agent. Basecamp's tools, its private "shaping track" and its six-week cycles do not automatically become policy for another team.

Appetite is not an estimate, and not a hidden promise

Appetite is how much we are willing to invest in this problem; an estimate is how much work or time we currently expect, under certain assumptions. The first constrains the choice of solution; the second is an uncertain forecast. Neither guarantees a date.

Concept	What it fixes	Example phrasing	What it does not promise
Appetite	An acceptable limit on effort or calendar time for this capability	"Let's consider a small solution we are prepared to give at most one agreed short cycle"	That every requested feature will fit within the limit
Estimate	The current forecast, with its basis and its unknowns	"With the calendar access we have, this duration seems likely; the integration needs checking"	That the forecast will not change once new facts arrive
Commitment	The responsible owner's decision to allocate a team or time to a specific scope	"After reviewing the pitch, exactly this result and these exclusions were agreed"	That the unknowns have gone or the risk is zero

In the fixed time, variable scope approach, the team holds the investment limit by cutting less valuable features in order to keep the result whole. That is not permission to cut security, necessary quality or legal requirements: narrow the functionality, choose a different solution or decline the bet. Singer cites one to two weeks for small bets and cycles of up to six weeks for large ones in his Basecamp team. That describes their practice; it is not a norm for A1, a universal task size or an estimate for an agent. Another team might think in hours, days, a month or a quarter, or ask for a short analysis first.

When the risk is regulatory, security-related, financial or about migration, do not reduce mandatory guarantees just to hold a fixed limit. Reduce the functional scope, investigate the assumptions, or do not take on the work until the precondition is met. Appetite limits the desired investment; it does not cancel a law, a contract or a condition for safe operation.

Working through the alternatives. The studio could limit the first version to viewing the next booking, or it could allow rescheduling. If what matters is only quick access to the accurate status, the limit should force rescheduling out, not remove the check on who owns the record. If the key value is avoiding a phone call to change the time, then viewing without being able to change the booking does not solve the relevant situation. Within the same limit, the team then looks for a simpler rescheduling operation, but it does not drop the invariant "never book a slot twice".

Narrow the problem and check there is something to shape

A raw request suggests the solution someone wants, but it does not yet prove that solution will solve the problem. Clarify:

1. Who exactly runs into the problem, at what moment, and what do they do today?
2. What fails, how often, for whom, and at what observable cost?
3. Which existing tools, constraints or decisions must be preserved?
4. What data will show that the problem has really shrunk?

In the chapter Set Boundaries, Singer describes how a request for more complex permission rules, once investigated, led Basecamp to a smaller solution: warning the user about the consequences of archiving instead of building an elaborate role system. Similarly, a request for "a calendar" was narrowed to a specific question about free time slots. These are examples from the author's experience, not proof that every large request hides a small solution.

If the symptom is real but the way to reduce it is unknown, it is not "an easy implementation task". Discovery has to come first: an investigation whose result may be observations, a short technical prototype, an integration test, a comparison of options or a reasoned decision not to continue. Do not paper over the unknown with "add a portal" until there is an explanation of why the proposed form should work.

Check business fitness too: who will answer the enquiries, whether this data may be stored, which privacy requirements apply, who pays for the external service, and whether the team has the authority to change the process. Discovering these conditions late can make a technically finished screen unusable.

The pitch as a bridge between problem and execution

For a potentially large change, a written pitch briefly covers five parts. In the chapter Write the Pitch, Singer describes this format as a way to present the problem, the investment limit, the solution, the risks and the deliberate exclusions, so that people can evaluate a potential bet:

1. Problem: a concrete case and the current state that does not work.
2. Appetite: the amount of attention the owner is willing to spend, and why.
3. Solution: the main elements, concrete enough to be evaluated.
4. Rabbit holes: assumptions, interdependencies and decisions that could change the odds of fitting within the limit.
5. No-gos: cases that are possible but deliberately excluded.

This does not mean creating a separate formal document every time. For a small fix, a paragraph in the task is enough. But when a solution is being discussed by people without shared context, a pitch helps them compare problem and solution and understand the price of a compromise.

Instead of "add a schedule to the portal", a pitch should name the change for the client, the boundary of the first version, the risks and the exclusions. In the full shaping example later in this unit, the page shows one upcoming booking; rescheduling depends on checking the calendar, and the target metric is set only after a baseline measurement.

Before and after. "Add a schedule to the portal" does not say what action the schedule changes or what will count as success. A shaped version might read: "A client who has a confirmed booking should be able to check their next appointment time themselves, without phoning. In the agreed limited version, the page shows one upcoming booking with its time zone; rescheduling is assessed separately once the calendar has been checked. We measure the number of enquiries specifically about times; the baseline must be established before any numeric target is announced. This version does not include a full profile or payment management."

The second version already lets a reader challenge its assumptions: perhaps the calls are mostly not about times, or a written page will not help people without an account. It also shows that checking demand and technical feasibility can come before the bet on implementation.

Find the rabbit holes and walk the path in detail

A rabbit hole is not every question with details in it. It is an unknown part of the solution that could make the team change the architecture, the access rights, the scope boundary or the likelihood of reaching the result. Finding rabbit holes starts with walking through the real scenario slowly: what the user has at the start, what they enter, what the system checks, when the record changes, and what they will see after a failure.

Question	What to check
Who has access?	The record's owner, the role and a server-side check, not just a hidden button
Where does the time come from?	The time zone, the source of truth and conversions between services
What happens in a conflict?	Two clients pick the last free slot almost simultaneously
What happens to the notification?	The success response and the email can diverge; when the booking is committed and whether there is a reliable retry
Is there a paid consequence?	Rescheduling may change the rate, the deposit or the refund rule; where the business decision is recorded

One rabbit hole in full: the race for the last slot. A prototype reads the calendar, checks that a time is free and then creates an event. Between the check and the write, another client can take the same slot. If the integration has no locking or atomic creation, the team cannot treat this sequence as a guarantee against double booking. Investigate whether the event can be created and the conflict handled at the source; whether a local reservation table with a transaction is needed; or whether the first version should be limited to internal slots that already have the invariant. The result of the investigation is a decision with a specific guarantee and a known residual risk. If access to the provider has not been granted yet, the answer honestly remains uncertain: an implementation plan is no substitute for evidence.

Risks that could change the idea itself are worked through earlier. A decision about a button colour should not come before checking whether the data source supports the required scenario. That does not mean investigating every small detail up front: find out what will affect the boundaries, security, cost or way of implementing.

Define what is out

A no-go is a deliberate boundary, not a forgotten acceptance criterion. It stops the person doing the work from adding a reasonable but unagreed extension. In the example, the boundaries around history and financial rules limit functionality, not mandatory quality guarantees.

In the first version	Not yet included	Why
Viewing the single next confirmed booking	History for all years and export	We do not increase data volume and storage requirements until the need is confirmed
Moving one booking to another free slot, if the integration supports it	Refunds and rate changes	Separate financial rules and agreement with the payment system are needed
Server-side owner check	Administrative editing of any record	That is a different role and a different access risk
Confirmation of the new time through a defined channel	Chat, attachments, profile and marketing notifications	These are additional products and personal data, not part of the core scenario

A clear no-go does not cancel the minimum necessary quality: the team does not exclude privacy, error logging or recovery after a partial failure just because a short pitch did not describe them. Do not derive specific security requirements from a "not included" line; they are determined by policies, risks and the material elsewhere in this course.

A technical task can be valuable, but not as a file name

Focusing on outcomes does not mean every task must add a user-facing feature. A technical change makes sense on its own when its result is measurable or necessary: the backup can be restored under specified conditions; the system stops leaking sensitive data; the import handles an agreed size; a dependency is supported; an operational risk is reduced.

Compare two formulations:

• "Add a table and an endpoint for the portal" specifies implementation details, but not a state that can be checked for the user.
• "An authorised client sees the current time of one of their own upcoming bookings; a request with someone else's identifier does not reveal the record" specifies behaviour and an important negative case.

The second description does not stop developers from choosing a table, an endpoint or another solution. It helps prevent unfinished storage from being passed off as a finished capability. If architectural work has its own result, for example that no new booking is read from an inconsistent replica any more, its owner explains whom or which risk it serves, how to check the result and who depends on the change.

How to recognise a task that can be done and accepted

A task should name its result, its boundary, the preconditions it needs and how it will be checked. For complex work, also clarify what must not break, which unknown needs investigating, who makes the decision that depends on it, and who accepts the result. Not every task needs separate fields: a text correction needs a few sentences, while access, data, migrations or side effects need explicit guarantees.

"Add a rescheduling screen" does not say whether the booking can be cancelled, what happens to the last slot, or whether the user has the right to change this particular record. It is better to define observable behaviour: the client sees the available slots; the server checks the owner and reserves the new slot atomically; in a conflict the current booking stays valid and the client chooses again. The team chooses the transaction approach and other technical details within these guarantees.

A clear, bounded task answers the following questions to the depth required:

1. Why: which result or risk does it touch?
2. For whom and where: which user, process or component forms the boundary?
3. What changes: which observable rule will be different?
4. What does not change: which adjacent guarantees or flows must not be broken by accident?
5. Preconditions: which decisions, permissions, environments or other tasks does it depend on?
6. Criterion: what evidence will let us say "done"?
7. Unknowns: what needs checking separately, and which choice depends on the answer?
8. Handover: who accepts the result, and where will the decisions and open questions be kept?

Not every task needs eight separate headings. A small correction to an explanation, for example, can fit its goal and acceptance into a few sentences. For a change involving access, data, migration and side effects, a skipped question can hide a whole separate piece of work.

Do not split a product by code layers when the user needs a whole scenario

The request "reschedule a booking" can be broken down by layer: create a table, change the server, add an endpoint, build a screen, send an email. No single layer gives the client a finished result: the interface may rely on a contract the server does not support, and the email may announce a change that has not yet been saved.

A scenario-based split gathers the data, the rule and the response around one whole result: the client sees their own booking, chooses an available time, and after a conflict keeps the old record and tries again. Email delivery may be delayed, but it must not make the saved booking state incorrect. This kind of split checks the full flow sooner, but it does not make the parts independent: they may rely on calendar permission, shared authorization or a rescheduling policy that has not been decided yet. Name these dependencies explicitly. Vertical slices are covered in depth in Vertical Slices.

A complete comparison. The large request "reschedule a booking" can be broken into horizontal layers:

1. create a reschedules table;
2. change the server;
3. add an endpoint;
4. build a screen;
5. send an email.

After the first step, neither the client nor the team sees any result. The interface may already assume a contract the server does not support; the email may announce changes that have not been saved. If the initial assumption was wrong, several layers have to be reworked.

The alternative split follows behaviour:

1. Show the client's own next booking. The consumer sees real data, with an owner check.
2. Choose an available time and see a conflict. Data, the slot rule and the message work together in a small scenario.
3. Confirm the reschedule and receive the new state. The commit, the protection against concurrency and a clear response are joined into one behaviour.
4. Add an extra notification only under an agreed rule. If email delivery is separate and may be delayed, the booking status must still be correct.

The second option exposes problems with the full flow sooner and leaves a checkable user capability at each step. It does not automatically guarantee that each part is independent: all of them may depend on the calendar provider's permission, the common authorization scheme or an undecided rescheduling policy. Bring the shared dependency out into the open; do not disguise it behind separate screens that only look finished.

Vertical Slices gives the full treatment. The rule that matters here is this: wherever possible, group tasks around a small whole result, and explain genuine technical preconditions separately.

Do not split work until coordination costs more than the work

An oversized task delays feedback: "build the whole backend", for example, hides six different decisions and has no point at which it can be checked. A board split too finely has a cost as well: "create a field", "add an import", "change a word", "update one snapshot" can demand more context transfer, dependency tracking, assignment and review than the work itself.

Signs that the split needs revisiting:

• two tasks have no separate completion criterion, because the first cannot be used or checked on its own;
• the person doing the work spends a lot of time reconstructing what five neighbouring tickets meant;
• one task "hands over" to another, even though their decisions have to be made together;
• the board advances the number of closed tasks but does not show whether the user completed the scenario;
• conversely, one task contains several independent results with different risks and acceptance conditions.

Merge parts when they rely on the same variable, their decision is made jointly and together they form a naturally checkable result. Keep a part separate when it has its own value, precondition or risk, or can be postponed independently. There is no universal limit such as "a task must take no more than a day".

In The Mythical Man-Month, Frederick Brooks warns against the idea that any amount of work can be divided into equal person-months at no extra cost. A person-month is a rough accounting unit, as if one person spends a whole month on a share of the work; adding them up only makes sense when the parts are sufficiently independent and need no extra training or coordination. The publisher's description of the anniversary edition links the management problems of large projects to the division of labour, and the table of contents names a separate chapter on communication. Treat this as a prompt to check dependencies, not as a formula for forecasting a modern team or an agent: does the new boundary really remove a dependency, or does it only add a handover between owners?

In his later essay No Silver Bullet, Brooks distinguishes the essential complexity of a design from the accidental difficulties of representing and implementing it. Automation can reduce some of the work with code, but that does not mean the product problem is solved: an agent cannot infer from file names whether the owner has approved the cancellation rule or the acceptable cost of a mistake.

Three different results: decide, investigate, implement

Unknown behaviour or an unagreed business rule is not a simple sub-item of implementation. Separate the kinds of work:

Work	When it is needed	What it hands on
Discovery / shaping	The problem, the user or the desired outcome is unclear	A choice of problem, and the observations that support or refute it
Spike (a time-boxed technical investigation)	The goal exists, but feasibility or integration constraints are unknown	A reproducible conclusion, known limits and a recommended next step
Owner's decision	The choice belongs to the business, the product or whoever is responsible for the risk	An explicit rule with its rationale and the decision's owner
Implementation	The boundaries and significant rules are known well enough	A checkable change that fits within the agreed behaviour
Operational action	Support, recovery or observability are needed after release too	Instructions, a signal, a responsible person or a confirmed recovery path

A spike that did not resolve the question can still be a success: for example, it may show that the provider offers no transactional guarantee of the kind online rescheduling needs. What matters is not to close it with "investigation complete" and push the unknown behaviour into code. The team has to adjust the concept, choose a different integration or stop this particular version of the solution.

A full shaping example: from "build a client portal" to a plan

The initial request and observations

The owner of a fictional studio asks: "Let's build a client portal so I get fewer phone calls." That is a direction, not a finished pitch. The conversation reveals a concrete situation: some clients do not remember the time of their next booking and phone during working hours; others phone to move their visit. The existing calendar is run by an external provider, and clients' access rights to it are still unknown. The studio does not yet count these two kinds of calls separately.

Stating the problem and the outcome

The first thing to test is whether a small ability to view the booking yourself will reduce enquiries about its time. The expected outcome: a client with a confirmed booking finds the current details and does not contact the administrator just to check them. Before launch, the team sets up a practical way to count such enquiries. No numeric target is invented without baseline data.

A draft pitch

Problem. Clients cannot always find the time of their next booking, so they phone the administrator. There is no data on how many such enquiries there are, or what share is caused by a lost confirmation email.

Appetite. The owner chooses a limited first version, provided it can be built without a new full CRM (customer relationship management system) and after a short check of the integration. Notionally the team is considering a small cycle; this is a decision about the desired investment, not a forecast of duration.

Solution. A link in the confirmation leads to a protected page showing one upcoming booking for the current client, with the date and time zone. If the calendar investigation confirms that a safe change is possible, the client can choose a new free slot and see the confirmed result. If another user took the slot, the old booking stays valid and the client chooses again.

Rabbit holes. Access to the external calendar, the server-side owner check, atomicity of slot conflicts, the rule for the latest time a booking can be moved, behaviour when a notification is delayed, and a baseline count of enquiries. The first three cannot be postponed until the moment a client is already relying on the record being correct.

No-gos. No profile with full history, no cancellation with refunds, no payments, no messaging, no staff administration, and no changing a booking via another person's phone number. Until it is established whether the source of truth supports rescheduling, that action is not an agreed promise.

The breakdown after checking the unknowns

Once the owner has agreed the need, the technical investigation has checked the integration and the unresolved business conditions have each been given an owner, bounded parts can be handed to the team:

1. Confirm the data and access path. Result: the source of truth is named; the team can retrieve the current booking of a specific current client; the negative case with someone else's record does not return their data. If such access does not exist, implementation waits for permission or a changed decision.
2. Let the client view one upcoming booking. Result: the confirmed time is shown with a defined time zone; when there is no booking, the page does not invent one and offers a clear next step. This slice on its own already tests the core need to view.
3. Add safe rescheduling only once the integration is confirmed. Result: within the agreed selection rule, the server reserves an available slot; a conflict does not cancel the old booking; the client sees the actual final state.
4. Find out whether the outcome changed. Result: it is defined how to compare "check the time" enquiries before and after access to the page, and what limitations the comparison has. The metric must not encourage hiding calls that are needed for complex help.

These titles do not automatically mean four Jira issues, and they do not assign people. The first may become a spike or, if the integration is already well enough understood, a precondition for the second slice. The second and third carry different business guarantees, so they are natural separate boundaries. The fourth can run alongside the launch under an agreed analytics scheme, rather than blocking every booking save.

What happens if a condition is not met. If the provider's calendar does not confirm that a successful reschedule neither creates a duplicate nor loses the old booking, the third item cannot be declared "almost done". The owner has three real choices: launch viewing only; first replace or supplement the integration; or not build the rescheduling scenario. This is a clear point for reconsidering the bet, not a deviation caused by a developer failing to estimate carefully enough.

A full example of an unknown dependency: the payment provider

Another team is adding a "Change time" button next to a booking that has already been paid for. It does not yet know whether the contract allows a payment to be moved, whether the amount will change, how the provider reports success (through an event or only a synchronous response), or what to do after a network timeout. After a timeout the state may be unknown, so a timeout is not proof of refusal. A task titled "connect the API" contains none of these decisions.

The raw version. "Implement payment rescheduling" names no supported operation, no owner of the business rule, no retries and no observable completion. An agent reading only that title might invent an endpoint or treat a timeout as a refusal.

A bounded spike. Questions for the person responsible for the provider relationship: which operations the current version of the integration supports; how to verify webhook signatures; when the result can be uncertain; which idempotency keys the provider accepts; which test mode is available; what the agreement allows regarding changing or refunding the amount. The output is links to specific official documentation and the studio's contract, samples with no secrets, the observable states, a list of answers that remain uncertain, and a recommended decision.

The resolution. If the system has an authoritative way to change a booking without a second payment, the next pitch can be limited to rescheduling at an unchanged price. If different slots require an extra payment, that variant is a separate change after explicit agreement. A sandbox response confirms the test flow, not production guarantees; the task is not marked done until it has been decided what should happen to the payment.

In a time-boxed investigation you can set a desired time limit, but the limit serves the decision "continue, narrow, or ask the owner"; it does not assume the provider is obliged to answer by the deadline. If access or a legal interpretation needs the owner, the agent hands that question over clearly instead of replacing the missing approval with a guess.

Real decomposition on GitHub: what it shows and what it does not prove

The public assimp epic #6097, "Requested 3D formats", opened in April 2025, collects requests for new three-dimensional (3D) file formats and for additional schemas or versions of formats already supported. When viewed on 23 September 2026, the card showed 21 of 57 linked sub-issues completed. The issue body calls the epic a log of requests, gives separate child issues for specific formats and describes how a PR (pull request, a request to merge changes into the main branch) relates to closing a specific issue. It also keeps the licensing question explicit: for one requested format it notes the restrictions of a proprietary licence.

This real example shows well why a parent card might aggregate many small, separately addressed requests: the project gains visibility over the collection, while implementing a specific format has its own issue. The epic label and the sub-issue counter do not prove that every child is the same size, that a decision has been made to support every format, or that the user outcome of the whole collection has been achieved. The recorded state of 21/57 is only the page's state on the date it was viewed; it changes.

In its own book Basecamp recommends shaping before a bet; GitHub's official documentation explains how the hierarchy of issues and sub-issues is represented technically. These serve different purposes: GitHub lets you show how pieces of work relate, but it does not decide whether the problem is well stated, whether the boundary is acceptable, or whether the team has created more tasks than it can coordinate.

A short decomposition workflow with an agent

This is an adaptation of the course's production standard, not a promise that any model will follow it without human review. Before creating a batch of tasks, ask the agent to go through this sequence:

1. Read the context. Review the request itself, the current code or process, related decisions and the source of constraints. Record which access is missing.
2. Restate the outcome and the constraints. Who should get which observable change? What must not be broken? What is explicitly out of scope?
3. Separate the known from the assumed. For each unknown, name the evidence needed to choose. An open question is not an accepted decision.
4. Propose shaping options. Show a smaller workable version and a fuller version, their benefits and risks, and what each deliberately excludes.
5. Mark dependencies and stopping points. For example, the calendar integration is needed before rescheduling; without a server-side owner check, viewing is not ready.
6. Define the completion criterion for each part. Explain how a person with context will check the real result, not just the presence of a changed file.
7. Ask for a decision where it belongs to the owner. Do not invent a refund policy, access rights, a bet or permission to change the product.
8. Only then reflect the agreed work in the tracker. Do not create dozens of tickets automatically before the boundaries are confirmed. After creating them, leave links to the pitch, the dependencies, the sources and the open risks.

A small example. For the request "update the help page", the agent notices there is one outdated button name, finds the current interface, and adds a short result and a way to check it. It does not create an epic just because a product task supposedly must have several levels.

A complex example. For "move all bookings to a new calendar", the agent first establishes the number of sources and formats, who owns the historical truth, the acceptable window without writes, how reconciliation will work after the migration, how to roll back, and the permissions for the external service. Until those facts exist, it proposes a bounded investigation and options, rather than silently building a migration plan out of assumptions.

The official write-up on long-horizon tasks with Codex shows goals, constraints, stages and verification criteria; the Claude Code documentation describes the --permission-mode plan option. These are features of specific products and versions, not the same guarantee across different agents. Whether an agent can see files, run processes or create tracker items depends on its tools, configuration and access. A plan is output to be reviewed and corrected: it does not confirm that its content is right, it grants no authority, and it does not make the user's data available.

Checking shaped work before handover

Before work starts, the owner and the person doing it should check that:

1. it is clear for whom and in which concrete situation the result changes, and the solution can be explained without guessing at essential behaviour;
2. the effort limits, what is in and out, and the guarantees that remain mandatory have been agreed;
3. the risks and dependencies are named, along with the evidence for checking them and the point at which an unknown stops or changes the solution;
4. each independent part has preconditions and an observable acceptance criterion, and the parts together preserve a whole, checkable scenario;
5. the result rests on facts, not on invented estimates, client data or an agent's promises;
6. the person doing the work is free to choose design and code details within the agreed guarantees;
7. it is known who makes the open business decisions, who accepts the result, and where decisions and questions will be kept.

If the pitch has a critical gap, more tasks will not close it: go back to the risk, narrow the concept or agree a separate check. Do not keep steps that merely move data between layers and cannot be assembled or checked as a whole result on their own. Once the residual risks are accepted, hand the work over and settle small details during execution.

Summary

Shaping produces a rough solution, solved to the right level and bounded; decomposition turns it into parts that can be checked and tied to a result for the user. Appetite limits the investment, an estimate forecasts the work, and these are different things.

Before splitting the work, state the problem, check the important product and technical risks, and name the boundaries and the unknowns. Group work around whole scenarios that can each be checked on their own; do not replace them with one big bucket or with a chain of small tickets that have no results of their own. An agent's plan helps the discussion, but human approval of the product decision, of access and of scope stays with the people who own them.

Sources and further reading

The main sources were checked on 23 September 2026, and the Codex and Claude Code documentation was re-checked on 26 September. The sources support the statements made; the unit's own examples and adaptations are marked as such.

1. Ryan Singer, Shape Up: Stop Running in Circles and Ship Work that Matters, Basecamp web book; viewed 23 September 2026. Chapters 2–6 support the description of shaping, appetite, narrowing the problem, risks and the pitch. Basecamp's cycles are cited as an example of their practice, not a universal norm.
2. Marty Cagan, "The Four Big Risks", Silicon Valley Product Group, 4 December 2017; viewed 23 September 2026. Explains the four kinds of product risk, which the text turns into questions for the example.
3. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 20th anniversary edition, 1995; the publisher's bibliography and a legitimate sample of pages from the edition were reviewed. The text uses the idea of division of labour as a caution, not as a quantitative law for modern teams.
4. Frederick P. Brooks Jr., "No Silver Bullet: Essence and Accidents of Software Engineering", first published in Information Processing '86; republished in Computer, vol. 20, no. 4, April 1987, pp. 10–19; viewed 23 September 2026. The publisher's excerpt was read. It supports the distinction between the essential complexity of a design and the accidental difficulties of representing it; applying that distinction to agent-driven decomposition is a teaching adaptation, not a claim based on measuring modern AI teams.
5. GitHub Docs: Adding sub-issues, current GitHub documentation; no update date shown on the page; viewed 23 September 2026. Explains how issues can represent a parent–child relationship and progress in Projects. This describes tracker capabilities, not a recommendation that all work needs a hierarchy.
6. assimp contributors, Epic #6097: Requested 3D formats, public GitHub issue opened 11 April 2025; viewed 23 September 2026. A real, changing example of a parent issue with child requests, its own workflow and a note on licensing. The figure 21/57 describes the page's state at the time of viewing and is not an assessment of the project's results.
7. Derrick Choi, "Run long horizon tasks with Codex", OpenAI Developers, 23 February 2026; viewed 26 September 2026. Publishes the author's experience of describing goals, constraints, stages, verification criteria and planning for a long Codex task. It is an example of a specific workflow, not independent evidence of any agent's productivity.
8. Anthropic, Claude Code CLI reference (CLI: command-line interface), current documentation; no update date shown on the page; viewed 26 September 2026. Lists, among other options, the --permission-mode plan mode. The documentation confirms that the option is available in Claude Code, not that the plans it produces are accurate or that it grants permission to change external systems.