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

Written by Robert Galen on May 2, 2011. Posted in Articles.

One 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.

Boulders

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?

Rocks

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:

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
Allow for various attributes: underline, bolding, sub/super script, italicize, etc…
Allow for a form of headings; 3 primary levels
Allow for indenting of text
Allow for lists (numbered and bulleted); single level first, then move to multi-level
Allow for alignment – right/left justified, centered, variable
Allow for do/un-do to include ongoing text activities
Establish a paragraph model (or a variety of models)
Show/hide ‘hidden’ formatting marks
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.

Pebbles

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:

As the editor, allow for underline attributes, so that users can embellish their text…
As the editor, allow for bold attributes, so that users…
As the editor, allow for italics attributes, so that…
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…

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

Boulders

Rocks

Pebbles

Wrapping Up

Suggested Terminology from this post:

Register for More Free Business Analyst Resources!