You think that because you understand one that you must therefore understand two because one and one make two. But you forget that you must also understand and - Sufi teaching story
The elements of a system, the software system being built, are the easiest parts to recognize. They're visible and tangible because they're in the backlog and scheduled for development. If we look closer - and accept the fact that these elements have interactions with each other - there is more to the solution than a pile of stories being implemented as slices of larger elements of needed capabilities.
The intangibles of the system, the interactions between these elements (slices), the realtime behaviors that produce or consume data, the emergent behaviors of the system resulting from the evolution of the system state from the systems execution are also critical to success.
If we only consider the sliced elements of the system, there is no end to the process. How small is too small? What is the appropriate size of the slice? Not from an effort point of view, but from a systems point of view? But more importantly what are the interactions between the sliced elements? This is dependent on the slices and their interfaces. This dependent on the interconnections, the relationships that hold the sliced elements together.
Without considering these interconnections and the dependencies on the sliced points - this is a Cut Set Optimization Problem - simply saying slicing provides benefits to estimating and execution has no actual basis in practice.
Here's how to tell the difference between an actual systems view and just a pile of sliced work:
- Can we identify the actual parts of the system? To the Atomic level. Not atoms of course, be actual standalone parts, whose further decomposition (slicing) adds no value and in fact may create more complexity.
- Do we know how these parts - the sliced work outcomes - affect each other? Both statically and dynamically?
- Do we know how these parts - the sliced work outcomes - produce effects that are different than the effect produced by themselves as standalone parts?
- Do we know how this integrated effect behaves over time to meet the actual needed capabilities the system is supposed to provide to those paying the bills?
Many of the interconnections in the system operate through the flow of information. This information holds the system together and enables the system to operate as needed.
Slicing is only useful if it answers to the questions above and most importantly those sliced parts fit in the overall structure of the system - the system architecture, both static and dynamic - to statically and dynamically provide the customer with the needed capabilities at the needed time, for the needed cost, and deliver the needed performance and effectiveness from those capabilities.
The least obvious part of any system - its function or purpose - is often the most crucial determinate of the system's behavior and its resulting success - Thinking in Systems: A Primer, Donella H. Meadows.
Take care so as to not fall under the siren song of simple approaches.
I have yet to see any problem, however complicated, which, when looked at in the right way, did not become more complicated - Poul Anderson, quoted in Arthur Koestler, The Ghost in the Machine.
Care when slicing to make sure you have an understanding of the system, the interaction of the elements, and the outcomes of those interactions that you don't break the topological structure needed to assure the proper flow of value to those paying for your work.