2012/04/07

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 appropriatelyEmergentEstimated, and Prioritized). And that is exactly where the SIP principles and laws come into the game.
SIP process consists of three phases named preliminarypreparatory 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 andsimplification 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 inone 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…