Extreme Scrum: Using SIP to Create a Matured Product Backlog – Part I: Partitioning


Do you know SIP? No? You should. SIP stands for Simple Iterative Partitions and has been developed by Roger Sessions some years ago. It is a methodology specifically focusing on the problem of controlling business and IT complexity. SIP focuses on managing critical aspects of enterprise architectures and promises a huge increase of the return on your IT investment. If you want to know more about SIP just visit the inventor’s homepage here.

But what is actually the reason I’m writing about SIP and enterprise architecture? Our goal, as stated in the title of this blog entry, is to create a matured product backlog, isn’t it? After I have read the book about SIP some months ago, I was quite convinced I could reuse the principles and laws defined by Sessions not only to create an enterprise architecture (I’m an architect too) but also for any other area where the complexity has to be controlled and finally reduced. And my first candidate was the Scrum’s Product Backlog.

As defined in the Scrum tutorial the Product Backlog is one of the Scrum’s artifacts. It is actually an ordered list of the project requirements. These so called product backlog items describe what has to be built and they are maintained by the Product Owner. The Product Owner decides, based on the business value, risks, dependencies etc. about the priority of each of the product backlog item. Those product backlog items are commonly written using the well-known user story format. All these activities are often called Product Backlog grooming.

It seems to be quite easy to create some user stories and prioritize them, isn’t it?… However it is not the case as you might already have experienced in one of your projects. Especially at the beginning of product backlog construction you will get into trouble looking for the answers to common questions like “how to define a good user story”, “how to group user stories”, “how to reduce complexity” and so on. Our aim is to have our Product Backlog DEEP defined (DEEP is an acronym coined by Roman Pichler and Mike Cohn and states for Detailed appropriately, Emergent, Estimated, and Prioritized). And that is exactly where the SIP principles and laws come into the game.

SIP process consists of three phases named preliminary, preparatory and iteration. For our goal the phase preparatory is the most interesting one. It comprises three sub-phases:

  1. Partitioning – grouping of the functionality
  2. Simplification – consolidation or removal of unnecessary functionality
  3. Prioritization – determination of priority based on business value, risks and other factors

As you can see, apart from prioritization the Product Owner will have to fulfill two additional tasks named partitioning and simplification that are not specified by the Scrum methodology.

So the next question is how to conduct partitioning and simplification? In case of partitioning the SIP proposes to use the Five Laws of Partitions, which I have adopted to our purposes. Important: according to the definition used by Session, a partition is a set of subsets that divide up some universe such that every element in the original universe ends up in one and only one of the subsets.

Let’s look now at these Backlog Partitioning Laws. I call them simply BaPaL. The first two laws are the most important ones:

First BaPaL: partitions must be true partitions in the mathematical sense. For the user stories, this means that the functionality must be broken up into a set of subsets such that every function ends up residing in one and only one of the subsets. In case of the user stories these subsets are called epics (it quite obvious I hope). I call this law the BaPaL of Disjunction.

As an example let’s take a simple webshop application. For such system the partitioning is always driven by the business domains so we can easy define such partitions like Sales, Order, Customer, Billing etc. In case of the Sales partition we can assume that a customer should be able to search for a product, to buy it, to return it, to register herself and so on. These are ideal candidates for our subsets because they are separated business processes. A bad candidate for an epic would be e.g. “Create a PDF-Document” subset (with user stories like “Create a PDF for Invoice”, “Create a PDF for User Profile”), because it is a generic functionality, thus it violates the BaPaL of Disjunction.

Second BaPaL: partition definitions must be appropriate to the problem at hand. For the user stories, this means that an epic must contain user stories that are closely related to each other. Ideally such relationship means that functionality defined in user story A always requires the functionality defined user story B and vice versa. I call this law the BaPaL of Synergy.

In our web shop example, let’s define one epic named “Buy a Product”. What are the user stories that are compliant with the BaPaL of Synergy? I would say these are “Search a Product by Name”, “Add a Product to Cart”, “Checkout”, “Create a PDF for Invoice” and so on. A bad candidate however would be the “Register User” user story, because it violates the BaPaL of Synergy. Why? The user stories in the epic “Buy a Product” don’t require the “Register User” user story (often you can buy products “ad-hoc” providing your data for the purchase purposes only) and vice versa, the “Register User” user story doesn’t require any user story from the “Buy a Product” epic (you can register yourself without buying anything). The “Register User” user story cleary belongs to the “Maintain User” epic and not to the “Buy a Product” epic.

The next two laws are about sizing. Equal sizing promotes easier managing, organizing and administering of the product backlog. Here they are:

Third BaPaL: the numbers of epics in a partition must be appropriate. For the user stories, this means that the number of epics that make up a given partition should be in the range of 3 to 10 (based on my personal experience). I call it the BaPaL of Equal Partition Size.

Fourth BaPaL: the size of the epics in a partition must be roughly equal. For the user stories, this means that you don’t want to end up with large differences between the amount of functionality in the different epics of the partition. I call it the BaPaL of Equal Content Size.

And the last law is about interactions between subsets:

Fifth BaPaL: the interactions between subsets in the partitions must be minimal and well defined. In practice, this means that you might have to define more than one user story to support functional interfacing like cross-cutting concerns (security etc.). I call it the BaPaL of Fortress.

Going back to our webshop example, in case a customer would like to register herself (using the user story “Register User” that is actually a part of the “Maintain User” epic) during the checkout process (using the “Checkout” user story that is part of the “Buy a Product” epic) this interaction “must be minimal and well defined”. In this case we should define an additional user story called “Proxy Register User” or similar, that contains tasks allowing this interaction and place it in the “Buy a Product” epic.

I hope I was able to convince you that by applying these laws you can create very good user stories; however your product backlog still won’t be perfect. In the second part of this blog entry I will talk about the simplification. Stay tuned…


  • Marc Clemens

    18. April 2012 von Marc Clemens

    Hi Adam,

    You wrote about a importend topic (anyhow is often to small considered), the product backlog.

    The product backlog is an important tool to help in the business of project management. Importent for tools is, to use an adjuvent tool for a specific task (and only use a tool for the adjuvent tasks).

    But the Product Backlog is often used for the wrong things. It has the purpose to steer the developement process. It is not a tool to manage, structure or design requirements. Though I think your described rules are helping more in managing and structuring the requirements.

    A good product backlog contains entries of differnt accuracy and size, because it doesn’t make sense to have small and accuate entries that will not developed in the next iterations. Therefore you should not cut a bigger entry (like an epic) in a set of equal sized smaller entries that contain all features of the big entry. Instead you quarry out only the smaller entries for next development steps and leave a bigger entry for the future.

    Furthermore the splitting of big entries schon be along the business process and not across it. So using your sample of “Buy a Product”, I wouldn’t split it in

    • “Search a Product by Name”
    • “Add a Product to Cart”
    • “Checkout”
    • “Create PDF”

    I think better is

    • “(Only) one Product to buy” – so only a simple checkout and the Create PDF is needed.
    • “buy one Product which you can choose” – a search and select possibility have to be added
    • “buy more than one Products” – a shopping card is needed and the checkout will be more complex

    The Product Owner (or the person who is responsible for the Product Backlog) have to manage, structure and design requirements, but I think, the Product Backlog is the wrong tool for this.

    Kind Regards,


  • Adam Boczek

    Hi Marc,

    Many thanks for your valuable comment. I agree with you that the product backlog is one of the “underestimated” but very important artifacts of Scrum.

    My idea is exactly to use the product backlog as one and only point of information for the requirements. I don’t want however to use product backlog directly for the project management, but I do expect to find there all required information about scope of a project. And additionally the process of product backlog grooming is an incremental process, so there is no requirement to fully structure it from scratch.

    Secondly I’m process-oriented person :), so all (as far as possible of course) epics are business processes in my product backlog. User stories however are structured in pillars (related to process activities) to support reusability of the components and knowledge transfer between team members, thus role-less teams.


  • Andreas Ebbert-Karroum


    interesting discussion 🙂

    First I have to object with your last statement, that user stories should be pillars to support reusability of the component. It should be the team’s concern how to support reusability of a component. It’s the team’s responsibility to create and design components, how can product backlog items support reusability of such?

    I do agree though, that you can use epics as part of a bigger workflow, and stories to gradually flesh out the epic – that’s more or less what you do in story mapping.

    Your post leaves me a little confused about the used terminology: partitions, subsets and set of subsets and how that maps to epics and stories. (IMHO epics and stories are the same, just of different size. so epics can contain epics or stories, stories are the leaf nodes). When I understood you correctly you propose, that partitions (business domain) should consist of epics (process), which contain stories (process steps). Right?

    Also I don’t yet understand, if you would like the stories functionally dependent (you say so in the 2nd BaPaL) or with minimal interaction (5th BaPaL). In order to gain the maximum degree of freedom to order the items in the product backlog, you should always strive for independant items (I in INVEST). Is that what you mean?

    Another thing that I noticed was, that the 3rd and 4th BaPaL say, that epics should be of comparable size, and contain one to two hand full of stories. If you do that for the whole backlog, you run into the problem that Marc mentioned: the product backlog is a living thing, you constantly reshape, resize, split, join and reorder items to maximise the value. Reading the 5 BaPaLs I get the impression, that this could be done as a one-time effort before development starts. A lot of that effort is than probably wasted, because you don’t need all of what you thought you need (maybe this is still coming in your second post about simplification…). On the other hand, you say that “the process of product backlog grooming is an incremental process”. How does that go together with the 3rd and 4th BaPaL?

    On a final note, I agree that the product backlog should contain everything that needs to be done to a product to get it released. When Marc says that “It has the purpose to steer the developement process. It is not a tool to manage, structure or design requirements,” I think he means that the PB should not contain all ideas that are currently in your head, but only what is relevant for the current release you are working on. (right, marc?). This is also how I read your post, so I think in that respect you two are on the same page. Marc did not say, that he want’s to use the product backlog for project management – actually, I don’t know what you mean with a project management tool. Something like MS Project?

    Thanks for the interesting thoughts,


Your email address will not be published.