Most agile teams use “stories” for agile planning, but there’s still some confusion as to what a story really is. This becomes a particular problem when a team is asked to estimate some grand feature which takes one bullet point on a marketing slide but might take several iterations to implement.

It can be tempting to fall back on traditional project management techniques and start a process of eliciting “requirements”, then splitting the big story into a slew of sub-components and tasks (all mandatory, of course) with a rippling gantt chart of dependencies and timescale. For an agile project, though, this is the “dark side”. and can easily distort the rest of the development and delivery process beyond all recognition.

What we need is a more agile way of digesting such large chunks of work and somehow turning the a single big “must have” into an iterative, evolutionary, adaptive prioritisation.

Marty Haught has some thoughts and suggstions on this topic (Handling Large Stories in Agile) but it seems to me that the core solution is to remember that the project as a whole is essentially just a large story, and so the large story may be approached in exactly the same way.

This is an important, but under-emphasised, aspect of an agile process. It is “fractal” and “self similar” in that it should have the same fundamental structure regardless of the level at which it is viewed.