You've all heard of the "inverted pyramid" style or writing newspaper articles, right?
You start with a short, punchy headline, you follow that by a paragraph (called the Lede) which sums up the article's 5W+H (Who, Where, Why, What, When and How), then you fill in the details, starting with the most important, working your way down, paragraph, after paragraph, until you finish. [You can read more about the general idea, here:http://www.stickyminds.com/s.asp?F=S13696_COL_2.]
In the old days, when the telegraph system was horribly unreliable, that structure allowed reporters to the most important to their editors. If they didn't get to to transmit everything, their editors still got the most important, and if the editors didn't have enough room for the entire article, they just snipped it (literally, I believe, with scissors) so that it would fit.
That's the analogy I mostly use to describe how Agile projects are structured. In my book, instead of "doing agile", they "invert projects".
Now here's the most interesting thing about the inverted pyramid method: reporters spend 80% of their time writing the LEDE paragraph. If they don't the rest of the article is crap (can I say crap here? oops, I, just did, twice). Reporters have a name for this: burying the lede.
In all the years I've been doing Agile, "burying the lede", is the 2nd most common mistake made by most teams - even the apparently well functioning teams. They're so, so, so busy efficiently writing code and done-doning stories, they lose sight of what the project is really about. They lose sight of the genuine-requirements - things like saleability (if I build it, will they actually buy it), which I've not mentioned here, yet, but I will soon.
The cure for this is easy, in principle: more Lede time.
By that I do not mean you should write big, the-system-shall documents. What I mean is that you should
(a) Spend no more than half a day, maybe spread over a week, figuring out your twomise (i.e. your twitter-promise, e.g. "1,000 songs in your pocket"),
(b) spend another few days figuring out your genuine business requirements for that project (and don't forget saleability), then write your requirements on no more than 1 single page. Some of your requirements will be binary (does it do this? Yes/No), some will be scalar (our current NPS is -40, our minimum requirement is to bump that up to 0, our desired is >10).
(c) Then ask: how will we know when we are finished?
---
I promise you that if you do this, you'll find two things:
(a) your projects will most likely be shorter and you'll do less coding.
(b) your product will be better.
In other words: Increase Lede Time, Decrease Lead Time.
