In agile there is a mnemonic INVEST. This term is one of those Holy Grails that is never subject to assessment within the agile community. I had a hands on experience with an agile tools vendor when we were selecting tools for a DOD program. When speaking with the guru's at the tool vendor, we mentioned multiple resources assigned to a single task and interdependence of the tasks and their deliverables.
You'd thought the devil himself had walked into the room. In systems there are always interdependencies and the work requires multiple skills working together on those interdependencies.
A reminder of INVEST
- I=Independent - The user story should be self-contained, in a way that there is no inherent dependency on another user story.
- N=Negotiable - User stories, up until they are part of an iteration, can always be changed and rewritten.
- V=Valuable - A user story must deliver value to the end user.
- E=Estimable - You must always be able to estimate the size of a user story.
- S=Small - User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
- T=Testable - The user story or its related description must provide the necessary information to make test development possible.
The ironies here are those suggesting that pure agile doesn't not require estimating seemed to have missed INVEST.
But here's the issue...
In our domain, we work on systems. Others may work on a bunch of stuff. Here's how to tell the difference
- Can you identify the parts?
- Do these parts affect each other?
- Do the parts together produce an effect that is different from the effect of each part on its own?
- Does the effect, the behavior over time, persist in a variety of circumstances?
If the I in INVEST is in fact true, then you're likely working in a bunch of stuff not a system. Bunch of stuff is likely de minims in ways systems are not.
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 notion of decomposing the work - slicing - into small chunks needs to be tested against the systems requirements to also develop and manage the interconnections between these sliced chunks of work. Interconnections in a tree system are the physical floes and chemical reactions that govern the tree's metabolic processes. Similar interconnections occur in software systems.
Slicing work below the level of these interconnections of the system elements looses sight of the interdependencies and therefore looses sight of the system.
Literally you can't see the forest for the trees.
It is the management of these interdependencies that is the Critical Success Factor for increasing the probability of success for the project. Be very careful falling for the holy grail of slicing, without also maintaining visibility to the system it's operations and the interdependencies between all the elements and all the work needed to produce these elements.
