In this long-form blog post, Jason Cohen takes a new approach to scheduling work as a product manager, which involves the popular rocks, pebbles, and sand in a jar analogy.

This analogy might not be new to you if you’ve read Stephen Covey’s books. He saw rocks as the big tasks, followed by pebbles as medium tasks and small ones as sand. If you start your day with small tasks, the metaphorical jar gets filled so much that rocks won’t fit into it. If you instead start with the rock(s), pebbles and sand will just fit beneath the rocks, and you get more big and medium-sized tasks done.

Rocks

Jason takes another approach: He not only sees rocks as the biggest, but also as the most important tasks. And he also widens the time horizon from just one day to multiple months (>= 3 months for rocks, 1–4 sprints for pebbles and ≤ 1 sprint or just some hours for sand).

The product manager has to make sure that the tasks with “dramatic, measurable impact”, aka the rocks, get done, while also not neglecting pebbles and sand. If you don’t get your rocks done, then there is a problem with your product management skills. Jason sees the most common issue as “executing Rocks that aren’t impactful enough”. As the decision to which rocks have to be tackled is one of the most significant strategic decisions of a product manager, these decisions have to be made upfront and not in an agile manner as your team’s development time depends on it. Because “if you’re climbing up the wrong mountain in the first place, being “agile” doesn’t help; the result is a team self-managing themselves into a mediocre, unfulfilling result”.

Sand

Coming to the sand: This includes simple tasks like iteratively optimising a UI, fixing some small bugs and so on. In a product’s development lifecycle, there are tons of those small tasks, “that are individually unmeasurable but that add up to a significant impact”.
But be careful: Do not try to estimate sand’s impact, nor try to schedule or prioritise sand the same way you would rocks. The overhead of this often takes much more time than implementing the task itself. Always consider which type of task you plan, how to get the best results from it. Or as Jason says it: “If you’re using the same processes to prioritise and define Sand as to define Pebbles or Rocks, the process is wrong”.
He also votes to let teams schedule sand for themselves: “If the management is constantly engaged in Sand-scheduling, something is amiss and needs to be corrected, and it’s always the manager’s fault”.

Pebbles

Now let’s get to the pebbles: “While Rocks are strategic, with a view towards winning over the next few years, Pebbles are tactical wins that have an impact in the following months, attacking the challenges you’re facing right now, or a great feature idea you can surprise customers with sooner than they expect”.
They are also important to implement and the “most effective use of the team’s precious time.”

Practical advice for scheduling

This leads to Jason’s practical advice on how to use this in practice (which is great, as many frameworks lack a description on how to use them in reality).
The sprint planning should look like this according to Jason:

1. Time-critical items, regardless of size. (Examples: security patches, bugs actively impacting customers, critical work for a launch or other event with an externally-imposed, immovable date)
2. One or more stories from the current Rock.
3. One or more stories from the current Pebble.
4. Sand

There are also many issues and problems that can arise. Those are explained in detail in Jason’s post.

See for yourself and read this outstanding article: https://longform.asmartbear.com/rocks-pebbles-sand/