Skip to main content

Product Backlogs: Boulders, Rocks, and Pebbles…Oh My!

Galen_BA_May3One of the hardest things to do in agile requirements is to break things down into constituent parts for execution. I use the term backlog grooming to represent this activity. There are a couple of key factors in it. First is the notion that you can’t (or shouldn’t) break everything down at once into small components of work.

Truly it’s not that you can’t. In traditional projects we almost always break things down into small, more granular pieces. That’s not that hard. What’s hard is doing this without any knowledge of the real-world aspects of the work, since you haven’t done any yet.

In agile projects you work from a Product Backlog or a list of features, to-do’s and activities that are all focused towards completing a project. The list is in priority order and is executed in that order. Not all elements of the list are defined at the same level of clarity or granularity. Why? Because it can often be a waste of time and you revisit the backlog often as you complete bits and pieces of the work.

My analogy is that a solid Backlog consists of different sizes of User Stories. There are boulders, rocks, and pebbles. Pebbles are finely grained stories that are ready for the very next sprint-i.e. high priority items. As priority decreases, the size of the stories increases-from Rocks to Boulders. In this post I want to explore the dynamics of these three levels of size for handling Product Backlogs represented by User Stories.


Let’s start out with an example of a Boulder. The project in this case is a Word Processor-something we’re all generally familiar with. Call it Microsoft Word or Google Docs.

The Boulder-level story is:

As a writer, I want to format text in a wide variety of fashions, so that I can highlight different levels of interaction with my readers.

That’s the description of the story itself. As you know, solid stories contain acceptance tests as well. Would you even create acceptance tests at this level? I suspect not.

Now if this was in a list of other Boulders, we wouldn’t work on it very often / much-particularly if it was a lower priority. But what if this was a relatively high priority and the Product Owner wanted us to get some traction on it? What would be the next step?



I’d say break it down into Rocks. In this case, these would still be rather large. They would be ambiguous and their priority would be fluid. So what’s the value in breaking them down?

So we can start to visualize the various parts of the Boulder and decide which Rocks to tackle first. So here are some Rocks pulled from the Boulder:

  1. As a writer, I want to allow for text font changes; 20-30 different font types, colors, so that I can highlight different levels of interaction with my readers
  2. Allow for various attributes: underline, bolding, sub/super script, italicize, etc…
  3. Allow for a form of headings; 3 primary levels
  4. Allow for indenting of text
  5. Allow for lists (numbered and bulleted); single level first, then move to multi-level
  6. Allow for alignment – right/left justified, centered, variable
  7. Allow for do/un-do to include ongoing text activities
  8. Establish a paragraph model (or a variety of models)
  9. Show/hide ‘hidden’ formatting marks
  10. Establish the notion of a “style set” that can be used to establish a collection of favorites

I’ll stop now because I’ve run out of energy, but we could clearly go on and on. I think this is a nice set of Rock-level stories for initial discussion. These are essentially ready for Backlog Grooming with the team. Clearly some of them border on Boulders in their own right and most if not all are quite large stories.

There are two activities that can help us break them down into Pebble-level stories. Having the team estimate them always helps. First the estimates will clearly tell you whether the Rock will fit into your sprint length. If it doesn’t, then you are truly forced to break it down further.

Even then, you don’t want to fill your sprints with Rocks that need the entire sprint to complete. That sort of end-to-end execution dynamic would be a very risky proposition and would potentially defer done-ness and delivery too late in the game. Point being – you want a variety of Pebble-level sizes to effectively load-balance and fill each of your sprints.

But estimation helps drive the discussion and decomposition.

The other activity that helps in decomposition is writing solid acceptance tests for your Rock stories. Let’s do one by example – using this Rock-level story:

Allow for various attributes: underline, bolding, sub/super script, italicize, etc.

We’ll start writing acceptance tests for it.

  • Verify that underline works
  • Verify that bold toggles for all font / color types
  • Verify that all combinations of all attributes can be combined
  • Verify that font size changes do not impact attributes
  • Verify that paragraph boundaries are not effected by
  • Verify that attributes continue in pre-text, post-text ; for example, if we bold a numbered list text, the number should be bolded

Now imagine this Rock story with and without the acceptance tests. I see it getting quite a bit larger as we peruse the tests and start considering all of the nuance and complexity of the Rock.

Without them I would probably have underestimated its’ size. I would also have fewer ideas around how to decompose it further-if that was required. With them I can start fully considering the size and breadth of the story. They drive done-ness checks as well; so would be an inherent part of our testing.



So, what would be good Pebble-level stories derived from the above Rock? Let’s attack some of the attribute characteristics individually and see if that helps:

  1. As the editor, allow for underline attributes, so that users can embellish their text…
  2. As the editor, allow for bold attributes, so that users…
  3. As the editor, allow for italics attributes, so that…
  4. As the editor, allow for sub-script attributes, so that

Since all of these Pebble Stories are sort of related, I could ostensibly bundle them into a theme. That would make sense in building them and in demonstrating their behavior. It might also make the testing a bit simpler.

I also suspect that I could bundle the acceptance tests for this theme together-simply to reduce the writing I have to do. I’ll copy a few of the above acceptance tests that might apply to the theme or collection:

  • Verify that font size changes do not impact attributes
  • Verify that paragraph boundaries are not effected by
  • Verify that attributes continue in pre-text, post-text ; for example, if we bold a numbered list text, the number should be bolded

Are examples of the bundled acceptance tests.

Wrapping Up

One of the hardest challenges in adopting agile methods is understanding the nuance associated with the “simple list” called a Product. It’s an organic list that the team needs to revisit time and again; breaking stories down and drilling into their details. Not trying to understand everything, but gaining sufficient understanding to (1) effectively size and plan a story for a specific sprint and (2) be able to have some design & construction idea so that the story isn’t a surprise in execution.

The other factor is that stories often (always) beget more stories. For example, as part of the above story we might write a story related to writing a tool to change font size and attributes dynamically across the spectrum of supported fonts and attributes. This would allow us to automate the process of testing this particular behavior.

So the Boulder-Rock-Pebble metaphor is intended to remind you of the requisite pattern of continuously breaking your backlogs down. I hope it helps in making your backlogs look more like this-


So, start breaking down those Boulders…

Suggested Terminology from this post:

  • Product Backlog – a prioritized list of work for the team to complete; aligned with a project or application release goal or goals
  • Backlog Grooming – periodic visit of the product backlog; refining stories towards execution and delivery; deciding gaps in knowledge and how to fill them
  • User Stories – from the Extreme Programming space; a small use case on a card/post-it note
  • Themes – collections of User Stories that make sense to implement together; usually driven by demo or testing considerations
  • Story size language:
  • o Boulders – Very Large stories; synonymous with Epic
  • o Rocks – Medium to large stories; small Epics or larger stories
  • o Pebbles – Small stories; ready for execution

Don’t forget to leave your comments below.