Time Boxing and Budgeting

Goal

Time boxing and budgeting prioritize by reversing the usual order: the resource is fixed first, a delivery duration or an amount, as a given that does not move, then the requirements that fit inside it are selected, by decreasing value, up to the limit. Time boxing fixes the time the team can spend, budgeting fixes the money available, and the mechanism is the same: the resource does not stretch to absorb the wishlist, it is the list that shrinks to fit the resource. This reversal addresses at once the two ways a team prioritizing under a constraint can go wrong: ordering its requirements by importance without ever saying where the work stops and discovering the ceiling by breaching it; or letting the ceiling drift request by request, until the announced date or budget no longer means anything.

BABOK places this approach among the four ways of prioritizing business analysis information, alongside grouping, ranking and negotiation. What separates it from the other three is a limit fixed in advance. Grouping classifies requirements into categories with no ceiling, ranking orders them with no ceiling, negotiation seeks agreement with no ceiling. Time boxing and budgeting are the only approach where a constraint is set first, independently of the requirements, and where the set of requirements becomes the thing that adjusts. BABOK notes that this approach is frequently used once the solution approach has been determined and most often when a fixed deadline must be met or when a solution is enhanced on a regular and frequent basis.

The decision it supports is the content of a constrained delivery: given a resource that will not move, which subset of requirements produces the most value under that ceiling and which ones are explicitly deferred or dropped. The deliverable is a set of requirements fitted to the time or the budget: the items retained, their cumulative cost against the ceiling and the items set aside with their value, so that the trade-off is visible. BABOK recalls that priorities are replayed when the environment, the stakeholders or the information change: the cut line is therefore dated and is replayed along with them.

Usage

When to use it

• Firm, non-negotiable deadline: regulatory go-live, contractual date, market window that does not move.
• Budget or headcount already allocated and capped: an approved amount, a contractual envelope, a headcount assigned for the quarter.
• Solution approach already determined: the open question is how much scope fits.
• Regular delivery cadence: each cycle is its own fixed-resource allocation, like a quarterly release train.
• Team velocity or cost estimation reliable: the adjustment is only worth as much as the underlying effort figures.
• Value priority already established: a ranking or MoSCoW pass supplies the fill order.

When not to use it

• No firm ceiling: if the date or budget remain negotiable, prefer ranking, which orders without a ceiling.
• Requirements not independently severable: delivering a subset yields a broken result, renegotiate scope through negotiation.

Description

Fix the resource before touching scope

The order of operations is the whole technique. The length of the time box or the amount of the budget is fixed first, as a given, before looking at which requirements exist. It is the point that separates this approach from a plain ordered list. A team that starts by estimating its requirements and then derives a duration is doing classical planning, where time is the output. Time boxing does the reverse: time is the input, fixed by an external constraint, a compliance date, an approved budget, a release rhythm. The Agile Business Consortium, the body that stewards the DSDM method from which time boxing takes its shape as a delivery practice, sums up the reversal in one sentence: fix the time, protect quality and manage scope through priority. The question stops being "how long will all of this take" and becomes "what is the most useful outcome we can deliver in the time available".

Establish or reuse a value order

Selection needs an order to draw from. Time boxing does not itself prescribe how value is scored: it consumes an existing ranking. If a ranking pass or a MoSCoW weighting has already been done, it is reused. Otherwise a light value score is enough, as long as it orders the candidates defensibly. This order is an input, and the quality of the final fit never exceeds the quality of the starting order.

Choose a way to fill the constraint

In practice, three ways of approaching the fill decision can be distinguished. None belongs to a body of knowledge: they are field practices.

• Fill by removal starts from the full scope, everything is initially considered in the batch and removes the lowest-value items until the total fits under the ceiling. It suits a starting scope that is already fairly agreed and broadly wanted.
• Fill by addition starts from an empty set, nothing is in it at first, and adds items in priority order until the next one would exceed the ceiling. It suits a candidate list that is long or uncertain, where a defensible minimal core is wanted first.
• Selective fill starts from an identified priority core, then adjusts, adding or removing items one by one to land as close to the limit as possible without crossing it. It is a blend of the other two.

Apply a quantified allocation discipline

Adding "until it fits" is only a discipline if the cut obeys a rule. The Agile Business Consortium gives one, concrete and quantified, drawn from the use of MoSCoW inside a time box: Must Have items should not exceed 60% of the available effort, about 20% of the effort is reserved for Could Have items as a margin, and Should Have items fill the rest flexibly. This rule turns filling into a defensible allocation: it deliberately keeps room for what the team can drop if estimates prove optimistic.

Add in order, track a cumulative, mark the cut

1. Add items in value order, keeping a running total against the fixed ceiling. Stop as soon as the next item would exceed the limit.
2. Treat inclusion as binary per item, in scope or out of scope. A half-built requirement usually delivers none of its value, and filling the ceiling to the last franc by slicing an item produces a result that costs without returning.
3. Resist opportunistic backfilling. Once an item exceeds the limit, do not reach further down the list for a cheaper item to fill the last francs. It buys little value, these are by construction low-priority items, and it consumes the margin the limit was keeping.
4. Record the cut line and its reason: the items retained, their cumulative cost against the ceiling, the items deferred and their value. The trade-off becomes visible and replayable when circumstances change.
5. Replay at the next cycle or as soon as a divergence appears. If actual costs or velocity depart markedly from the estimate mid-delivery, refit rather than absorbing the gap silently as scope creep or a slipping deadline.

Three pitfalls decide the rest, and all touch the reliability of the figures and the firmness of the ceiling. The first is the padded estimate. BABOK notes, for prioritization in general, that the solution team may overstate or understate implementation difficulty, deliberately or not. For time boxing the consequence is direct and worth isolating: an item can be pushed out of the batch or protected inside it, by an inflated or deflated cost figure. The cut turns on cost, so cost gets manipulated. Cross-check estimates before trusting them to decide. The second is false precision: treating a fixed budget as divisible to the last franc when the underlying estimates carry real uncertainty, often around half at early stages. This is exactly what the 20% margin exists to absorb, and filling a ceiling to 100% on soft figures is a pitfall in itself. The third is the drifting ceiling: if the "fixed" date or budget move once the fit is done, the whole exercise was theatre. The discipline pays off only if the resource is held fixed, which is a governance decision as much as an analysis one.

AI considerations

The most rewarding assistance is purely mechanical. A model or a simple formula holds the running cumulative and flags, instantly, the item that crosses the limit, which returns to the team the time it spent on arithmetic and puts it back on the real trade-offs, the swaps of items near the cut. The second use is the quick comparison of several candidate fills under the same ceiling, by removal, by addition, by adjusted core, so that stakeholders compare several concrete cuts before committing. The third is spotting outlier estimates, the item whose cost figure carries far more uncertainty than the others, before it is used to decide what fits.

Three things stay out of a model's reach, and they follow from the nature of the decision. AI does not set the value scores: they encode stakeholders' judgement of what matters, precisely what BABOK notes as potentially subjective for want of indicators. AI does not settle the close calls at the cut: when two items of neighbouring value straddle the line, the decision often turns on context absent from the backlog data, a promise already made to a customer, a political sensitivity, that the model does not see. And a cost estimate produced by a model is worth no more than it is: a plausible figure is not a substitute for the team's own estimate, and taking it as one reintroduces false precision into the ceiling itself.

Examples

A retail bank's digital-channels team has a fixed budget of CHF 120'000 for the next quarterly release of its mobile app. Under the selective fill, candidate requirements are ranked by value and then added in that order until the next one would exceed the budget.

The first five requirements fit under the ceiling, the sixth in value order would cross it. The remaining CHF 2'000 margin is the limit held. Dark mode costs CHF 8'000 and might seem to "fit" within a CHF 120'000 budget, but adding it would take the cumulative to CHF 126'000, above the ceiling, and reaching for it because it is small would mean preferring a value-2 item over the discipline of the cut. The cut line is what separates this technique from ranking: ranking would have stopped at an order; the ceiling turns that order into an inclusion decision.

Visualizations

Two representations carry the technique, each showing a distinct thing. The selection is made of rows and columns, requirement, value, cost, cumulative, decision: the deliverable is the table itself. Its value lies in the running cumulative read top to bottom and in the cut line crossing the list. An image of this table would lose both: it does not sort, does not recompute when an estimate changes and does not let the cut be moved to see what tips over. The table also keeps visible, for the deferred items, the cumulative they would reach if added, which shows the reason for deferral.

The capping mechanic, by contrast, is spatial and does not fit in a table. A fixed resource forms a ceiling, the requirements stack up under it by decreasing value, and the line where the cumulative meets the ceiling separates what is delivered from what is deferred. It is this image, the ceiling on one side, the stack rising to it, the cut spilling over on the other, that conveys at a glance the reversal of order at the heart of the technique: the resource is set first, the scope adjusts beneath it. It is drawn in boxes and levels.

Cost

Tools

The spreadsheet is the honest choice, and it is better than most dedicated tools for a precise reason: the cumulative and the cut are formulas there. A running-sum column and a formatting rule that colours the first row whose cumulative exceeds the ceiling apply the technique automatically, and moving a value or an estimate recomputes the cut instantly. It is also where several candidate fills under the same ceiling are compared without effort.

Backlog-management tools, Jira, Azure DevOps and their like, carry the raw material when the time box is an iteration: effort points or a per-item estimate, a team capacity per cycle and a priority order in the backlog. The iteration's capacity plays the role of the ceiling, and selection amounts to pulling from the top of the backlog until it is exhausted. Their limit is that these tools reason in team effort: for budgeting in francs, the spreadsheet stays more direct.

That leaves the common wrong choice, the slide. A prioritization table in a presentation is the photograph of a decision: it does not recompute when an estimate moves, does not let the cut be shifted and it is wrong as soon as the ceiling or the figures change, which is very soon. The table lives where the team works and versions, next to the plan and the backlog.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.33 Prioritization: the definition of time boxing and budgeting as the allocation of a fixed resource, its place among the four prioritization approaches, the usage notes specific to this approach (solution approach determined, fixed deadline or regular and frequent releases) and, for prioritization in general, the limitation of over- or understating implementation difficulty.
• Agile Business Consortium, What is Timeboxing?: the reversal "fix the time, protect quality, manage scope through priority" and the MoSCoW-within-timebox allocation rule, Must Have items at no more than 60% of the available effort and about 20% reserved for Could Have items as a margin.