I have written a good few blog posts that have died, unfinished and unpublished because the nebulous idea I was trying to express was just too complex. Small is beautiful in blogging.
One of the key characteristics of a feature which we used in rolling out our agile methodology was that it had to be small. This could be defined by technology or the business:
Either by the development estimate — a few story points of under a couple of weeks of pure development
Or by a way of describing the business feature — for instance a one sentence description in what the user might see differently
Business users quickly get the idea, and technology loves it.
This has a number of great advantages. First up, you can fit a few features in an iteration and still keep iterations short. Next, if some features do take longer than expected or your velocity system has not kicked in yet it is easy to drop a feature or two from an iteration, keep to your plan and still deliver business value. Lastly and perhaps most importantly, small features are exponentially easier to define requirements for, develop and test for. As you add a little more complexity to a feature, the time it takes to go through the development lifecycle takes exponentially longer sine each piece can interact with the rest of the feature.
This principle — which is known elsewhere as “Keep It Simple” — can applied to a variety of other domains with great success. Simple works. It is also a great definition of agility. Simple means small and simple means only doing what you need and no more. Without simplicity, testing is hard and it’s hard to deliver the constant stream of business value needed to build the groundrock of an agile rollout: trust.