A product backlog is shaped like an iceberg because it reflects the varying levels of detail and size of product-backlog items according to their priority
and when they're expected to be worked on.
At the top of the iceberg, above the waterline, are the small, well-defined items that are ready to work on in the next sprint or two.
These items are detailed enough for the team to understand and implement without needing much additional clarification.
They're small enough for the team to complete multiple items per sprint, typically about one and a half to two items, per person.
This provides the Team with a clear and actionable plan for their immediate future.
As you move deeper into the backlog, items become larger and less detailed.
These medium-sized items are likely to be worked on in the coming months, but are not ready for immediate development.
They act as placeholders for upcoming work, and they'll be refined and broken down into smaller items as they approach the top of the backlog.
This gradual refinement process prevents the team from spending time prematurely breaking down items that may change or might never be implemented.
At the very bottom of the backlog, below the waterline, are the largest items.
Big ideas or high-level features that remain mostly conceptual.
These items require minimal documentation, often just a few words, because they're not expected to be addressed for a long time,
if ever.
For example, for many years, the travel website Orbitz would allow users to book airline tickets, rental cars, or hotel reservations.
Users could not reserve a cabin on a cruise ship.
When Orbitz finally added cruise ships, it wasn't because someone had just thought of it.
I have a great idea.
Why don't we add cruise ship to the site?
I'm sure the cruise-ship backlog item had been thought up years earlier.
And for items, either it languished at the bottom of the product backlog or was so low priority no one even wrote it down.
This approach avoids unnecessary effort and allows the Product Owner to focus on the most immediate needs.
The iceberg metaphor effectively illustrates the dynamic nature of a product backlog.
As the team completes items at the top, the backlog floats up, bringing larger items from below the waterline closer to the surface.
These larger items are then split into smaller, more detailed stories to maintain the iceberg shape, with small items at the top,
medium-sized items in the middle, and large, undefined items on the bottom.
This structure ensures the team always has a manageable, prioritized set of work ready while minimizing wasted effort on distant future items.
It also embodies the principle of just-in-time refinement, where the level of detail increases only as the work becomes more imminent.
If you'd like your team to go deeper on this, learning how to refine split stories and keeping your backlog healthy, check out our Working on a Scrum Team course.
It's designed for whole teams to practice these skills together and can be taken privately or as a public class.
You'll find links about this class in the description or drop me a comment to find out more.