First Step to Heaven: Agility of Inception, Partitioning of Epics, Creating Agile-enabled User Stories
The definition of heaven is quite simple: on time, in budget, in quality, and in scope. The road to heaven is quite complicated, we know that. Happily
there are a lot of patterns and practices that slowly covers more and more software engineering disciplines, making the challenge manageable. We know
how to document user stories, how to estimate them, how to prioritize them, how to implement, test, and roll-out them. In case of user stories we know
even how to split them. Look at this interesting Richard Lawrence’s proposal Patterns for Splitting User Stories about various
patterns that can be involved in splitting (however I don’t agree with the reasonability of some them).
We even know what the user stories should be: they should be INVEST. But we still don’t know how to start to write them to make them simply agile-enabled! Agile-enabled hmm, what’s that? Just think in the categories that a user story is THE starting point for all project
activities I have described shortly above: estimating, prioritizing, implementing, testing etc. So, user stories that are agile-enabled have the
following characteristics, they are:
I have read this year an ingenious book written by Roger Sessions about enterprise architectures, how to create them and how to reduce their complexity (Simple Architectures for Complex Enterprises, MS Press 2008) and how to use the simple iterative partitions (SIP) process. And I have suddenly recognized, as one of the conclusions I had, that the proposed by Roger methods and tools can be adopted to use them as the foundation for creating agile-enabled user stories!
However, above all, the agile-enabled user stories have to be business oriented. First, only such user stories can be understood by the business guys (clear ;) and only such user stories can guarantee a good quality delivered by the development, because the dev guys have to understand what and why they build. Second, agile is about learning and agile is about communicating. How to write a user story that will support learning and communication? Yes, a user story has to be understood by all parties involved; equals business oriented. So, forget any other ideas like e.g. technical user stories (they are simply not partitionable, but about it, in a moment ). However, don’t worry, the cross-cut concern technical functionality like persistence layers, aspects, logging etc. will be extracted and make reusable throughout the refactoring of exiting components within future phases of the project.
To create agile-enabled user stories I propose to use mathematical partitioning and its laws. You should use it as an element of the agile orientation system (agile culture), means as a one of the agile culture standards you would like to have within your organization.
According to the definitions used by Roger, 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 . What? Oh, come on, we use this way of grouping functionality since years starting with domain driven design etc. In every organization you will learn about domains like Customer, Order, Billing, Contract etc. If you look at any software system that supports business you can recognize some basic “functional columns” named domains. They can make up our partitions (for the start).
So let’s look at the Five Laws of Partitions. I will use here Roger’s definitions adjusted by me for the purpose of creating agile-enabled user stories:
First Law of Partitions: partitions must be true partitions in the mathematical sense. For agile-enabled 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 our agile-enabled user stories these subsets are called epics (yeah, I know you knew :).
Second Law of Partitions: partition definitions must be appropriate to the problem at hand. For agile-enabled user stories, this means that an epic must contain user stories that are closely related to each other. This means that functionality must be assigned to the epic based on the equivalence relation synergistic. Any two user stories are synergistic if the functionalities defined by them are functionally related to each other (I know, it sounds a little bit unclear).
Third Law of Partitions: the numbers of epics in a partition must be appropriate. For agile-enabled user stories, this means that the number of epics that make up a given partition should be in the range of 3 through 10.
Fourth Law of Partitions: the size of the epics in a partition must be roughly equal. For agile-enabled 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.
Fifth Law of Partitions: 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.
By applying these laws you can build perfect agile-enabled user stories. But it is the first step to heaven. The second step is the simplification. However it is a topic for another post.
---
- Simple in topic (but not trivial)
- Similar in shape (same size)
- Universal (supporting role-less teams)
- Self-contained (no additional explanation needed)
- Dispatch-able (to the teams and member)
- Manageable (supporting easy task specification and estimation)
- Reasonable (hmm, “human-able”)
I have read this year an ingenious book written by Roger Sessions about enterprise architectures, how to create them and how to reduce their complexity (Simple Architectures for Complex Enterprises, MS Press 2008) and how to use the simple iterative partitions (SIP) process. And I have suddenly recognized, as one of the conclusions I had, that the proposed by Roger methods and tools can be adopted to use them as the foundation for creating agile-enabled user stories!
However, above all, the agile-enabled user stories have to be business oriented. First, only such user stories can be understood by the business guys (clear ;) and only such user stories can guarantee a good quality delivered by the development, because the dev guys have to understand what and why they build. Second, agile is about learning and agile is about communicating. How to write a user story that will support learning and communication? Yes, a user story has to be understood by all parties involved; equals business oriented. So, forget any other ideas like e.g. technical user stories (they are simply not partitionable, but about it, in a moment ). However, don’t worry, the cross-cut concern technical functionality like persistence layers, aspects, logging etc. will be extracted and make reusable throughout the refactoring of exiting components within future phases of the project.
To create agile-enabled user stories I propose to use mathematical partitioning and its laws. You should use it as an element of the agile orientation system (agile culture), means as a one of the agile culture standards you would like to have within your organization.
According to the definitions used by Roger, 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 . What? Oh, come on, we use this way of grouping functionality since years starting with domain driven design etc. In every organization you will learn about domains like Customer, Order, Billing, Contract etc. If you look at any software system that supports business you can recognize some basic “functional columns” named domains. They can make up our partitions (for the start).
So let’s look at the Five Laws of Partitions. I will use here Roger’s definitions adjusted by me for the purpose of creating agile-enabled user stories:
First Law of Partitions: partitions must be true partitions in the mathematical sense. For agile-enabled 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 our agile-enabled user stories these subsets are called epics (yeah, I know you knew :).
Second Law of Partitions: partition definitions must be appropriate to the problem at hand. For agile-enabled user stories, this means that an epic must contain user stories that are closely related to each other. This means that functionality must be assigned to the epic based on the equivalence relation synergistic. Any two user stories are synergistic if the functionalities defined by them are functionally related to each other (I know, it sounds a little bit unclear).
Third Law of Partitions: the numbers of epics in a partition must be appropriate. For agile-enabled user stories, this means that the number of epics that make up a given partition should be in the range of 3 through 10.
Fourth Law of Partitions: the size of the epics in a partition must be roughly equal. For agile-enabled 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.
Fifth Law of Partitions: 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.
By applying these laws you can build perfect agile-enabled user stories. But it is the first step to heaven. The second step is the simplification. However it is a topic for another post.
---
Comments
Post a Comment