Big Rocks Methodology

The big rocks methodology is a planning rule that schedules the few large commitments first and fits smaller work around them. Sequence is the whole idea — the same jar holds far less if the sand goes in before the stones.

The image comes from a demonstration. Fill a jar with gravel and sand and the large stones will not fit. Place the stones first and everything else settles into the gaps.

Applied to a quarter, it means naming three to five outcomes that matter most, booking the capacity they need, then allowing routine work to occupy whatever remains.

What makes it hard is not the arithmetic. Routine work arrives with deadlines and named requesters, while a big rock arrives with neither — so it loses every contest unless its capacity is protected in advance.

The method is also a communication device. Naming three priorities publicly tells everyone what may now be declined, which is harder to do and far more useful than publishing a list of twenty.

Key takeaways

• Large commitments are scheduled first and everything else fills the remaining capacity.
• Three to five big rocks per quarter is the usual working limit.
• Each rock needs a named owner and booked capacity, or it is an aspiration.
• The method fails when urgent routine work is allowed to claim protected time.

How it works

The cycle is short. Name the candidate rocks, test each against available capacity, cut the list until it fits, assign owners, then block the time before any other commitment is accepted for that period.

Capacity testing is the step that gets skipped. A team with four people and a heavy support load may have only one person-month of discretionary effort in a quarter — which makes two big rocks the honest ceiling rather than five.

Review cadence keeps the rocks alive. A fortnightly check on each rock’s progress, held separately from the routine work review, is usually what stops them being quietly abandoned in week six.

Agile practice reaches the same problem from another direction. The UK service manual notes that flow-based methods suit teams that need to “react quickly to changing priorities”, while Scrum’s fixed sprints protect a committed scope for a set period.

Engineering programmes formalise the same protection through lifecycle gates. NASA’s systems engineering handbook exists precisely to improve “the efficient and effective engineering of NASA systems” by sequencing commitments rather than leaving them to arrive.

Examples

The method shows up under a variety of names wherever capacity is genuinely scarce rather than merely tight. The three cases below apply the same rule at team, function and whole-company level.

An operations team names two rocks for the quarter and books forty percent of capacity for them. Its workflow outsourcing arrangement absorbs the routine queue that would otherwise consume that time.

A finance function ties each rock to a line in the annual plan. The link makes strategic planning operational, because every strategic line now has booked capacity behind it.

A scaling business limits itself to three company rocks per quarter. Anything else waits, which is how it converts intent into transformational growth rather than a longer list of started projects.

Related terms

Prioritisation methods overlap heavily, and the differences are mostly about what gets protected. The entries below each handle a different part of turning intent into delivered work.

• Program manager: the role that usually owns the rock list and defends the capacity.
• Agile transformation: a change programme that is itself commonly run as a big rock.
• Project manager offshore: delivery capacity that can be added to make a rock fit.
• Research outsourcing: a way to shrink a rock by contracting out its discovery phase.

FAQ

How many big rocks should a quarter hold?

Three to five for an organisation, two to three for a single team. Beyond that the protection becomes nominal and everything slips together.

Is this the same as MoSCoW prioritisation?

No. MoSCoW ranks requirements within one piece of work. The big rocks method allocates capacity between competing pieces of work.

What counts as a big rock?

Something that will not happen unless capacity is reserved for it, and whose absence would be noticed at the end of the year.

Who decides the rocks?

The leader accountable for the outcome, after a capacity check with the teams. Lists assembled by consensus tend to include everybody’s item.

What happens to work that does not fit?

It is explicitly deferred rather than quietly carried. An unspoken backlog reappears as the reason the rocks were not delivered.

Does the method work alongside agile delivery?

Yes. Rocks set what a team commits to over a quarter; sprints or flow decide how that commitment is delivered week to week.

Read more planning and outsourcing guidance at Outsource Accelerator.