Second Step to Heaven: Scope Simplification using Partition Refactoring and Partition Reduction
In the first part of this blog series I have discussed how
to use SIP process ideas (Simple Iterative Partitions created by Roger Sessions) to define the scope of a system to be built, using clear defined partitions, epics and agile-enabled user stories (AEUS).
However we can still run some actions to make the system to be simpler by making it compliant to the laws of simplification. Once again I will reuse definitions and terminologies defined by Roger and adjust them to suit my needs.
Let’s look at the adjusted First Law of Simplification:
Subclasses of a partition should be constructed with the synergistic equivalence relation. From an agile-enabled user stories perspective, this means that an epic should be further decomposed, if possible, so that functionality is distributed across lower level epics by synergy. In other words, by placing together functionality that is logically inseparable.
How to achieve this goal? First of all you have to check if all your user stories are Minimum Marketable Features (MMF). According to the definition I found in the “Software by Numbers” by M. Denne and J. Cleland-Huang (Prentice Hall, 2003), a MMF, as the name implies, is characterized by the three attributes: minimum, marketable, and feature. The ideal MMF is a small, self-contained feature that can be developed quickly and that delivers significant value to the user. So your task is to identify the minimum or smallest possible group of features that deliver significant value to the user.
Secondly you can check if your agile-enabled user stories are compliant to some well-know software design principles like Separation of Concerns and Single Responsibility Principle. All these principles use the simplification as a foundation for their definitions.
I call this sub-step partition refactoring or, as proposed by Roger, continuous partitioning.
The Second Law of Simplification, which was also adapted a little bit by me, states:
Any functionality that can be removed from a partition or epics should be removed.
It is important to understand at which level you are allowed to remove functionality. You should, if possible, remove epics as a whole (if all user stories are dispensable) from a partition or user stories from epics. However you should avoid the removal of functionality direct from the user stories because you can change their context, thus breaking some of the partitioning laws.
Which user stories are candidates for the removal? Let’s look at them here:
· Remove user stories with so called “maybe we will need it” functionality. “Maybe” is out of scope.
· Remove user stories with solely horizontal (boilerplate) functionality. As stated in my previous posts, an agile-enabled user story is business oriented.
· Remove user stories that explain “how”. Leave only “what” user stories.
· Remove all non-ideal MMFs, as defined above.
This second sub-step I call partition reduction.
Both partition refactoring and partition reduction are core elements of the scope simplification.
So, two steps are done: partitioning and simplification. The next, third step on the road to to heaven is the prioritization.
---
However we can still run some actions to make the system to be simpler by making it compliant to the laws of simplification. Once again I will reuse definitions and terminologies defined by Roger and adjust them to suit my needs.
Let’s look at the adjusted First Law of Simplification:
Subclasses of a partition should be constructed with the synergistic equivalence relation. From an agile-enabled user stories perspective, this means that an epic should be further decomposed, if possible, so that functionality is distributed across lower level epics by synergy. In other words, by placing together functionality that is logically inseparable.
How to achieve this goal? First of all you have to check if all your user stories are Minimum Marketable Features (MMF). According to the definition I found in the “Software by Numbers” by M. Denne and J. Cleland-Huang (Prentice Hall, 2003), a MMF, as the name implies, is characterized by the three attributes: minimum, marketable, and feature. The ideal MMF is a small, self-contained feature that can be developed quickly and that delivers significant value to the user. So your task is to identify the minimum or smallest possible group of features that deliver significant value to the user.
Secondly you can check if your agile-enabled user stories are compliant to some well-know software design principles like Separation of Concerns and Single Responsibility Principle. All these principles use the simplification as a foundation for their definitions.
I call this sub-step partition refactoring or, as proposed by Roger, continuous partitioning.
The Second Law of Simplification, which was also adapted a little bit by me, states:
Any functionality that can be removed from a partition or epics should be removed.
It is important to understand at which level you are allowed to remove functionality. You should, if possible, remove epics as a whole (if all user stories are dispensable) from a partition or user stories from epics. However you should avoid the removal of functionality direct from the user stories because you can change their context, thus breaking some of the partitioning laws.
Which user stories are candidates for the removal? Let’s look at them here:
· Remove user stories with so called “maybe we will need it” functionality. “Maybe” is out of scope.
· Remove user stories with solely horizontal (boilerplate) functionality. As stated in my previous posts, an agile-enabled user story is business oriented.
· Remove user stories that explain “how”. Leave only “what” user stories.
· Remove all non-ideal MMFs, as defined above.
This second sub-step I call partition reduction.
Both partition refactoring and partition reduction are core elements of the scope simplification.
So, two steps are done: partitioning and simplification. The next, third step on the road to to heaven is the prioritization.
---
Comments
Post a Comment